|
It's the people not the tool. I am sure many people here treat programming as an art form professionally.
In this line, it just too easy to delivery something that works on the surface initially but slowly cracks under the pressure of business changes and requirement. Too bad usually the guy who delivered has gone and the guy who inherited it has to fix the problems left by the first guy, usually without much choice but by patching the system and making it worse.
Those system were done by Japanese and Singaporean, am I racist? 
|
|
|
|
|
GriffinPeter wrote: this entire project qualifies as a coding horror
By the sounds of it, I agree.
GriffinPeter wrote: I couldnt paste any sample code
Thanks for saving us the pain  I'll just take your word for it 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
I encountered the exact same thing with some US cobol programmers that couldn't quite grasp OO. Everything was a function that never returned anything, global variables everwhere. No concept of namespace or types and hard coded "if" statements.
modified on Sunday, July 13, 2008 9:26 AM
|
|
|
|
|
I was delving into code for other modifications and came upon some previous programmer's apparent confusion...
Supposing you had a value in double (c++) format and wanted to convert it to a 20.12 fixed point format contained in a 32-bit value. The source value was guaranteed to also not be larger than what the 20 bit integer portion could represent. How would you go about implementing this conversion? Think about it. Meanwhile, here's the code I found (suitably cleansed of any incriminating information):
uint32 ConvertDoubleToFixedPoint32_12(double temp)
{
uint32 whole;
double getFrac;
uint32 fraction;
whole = (uint32)temp;
getFrac = (double) whole;
fraction = (uint32)((temp - getFrac) * 4096);
whole = whole << 12;
whole |= fraction;
return whole;
}
Got that? 
How would you have done that same conversion? Scroll down to see an alternative...
static inline uint32 ConvertDoubleToFixedPoint32_12(double temp)
{
return (static_cast<uint32>(temp * 4096));
}
Sigh...
|
|
|
|
|
As it's C++, define a macro. 
|
|
|
|
|
Macros are not considered "best practice". I use them where I feel it is warranted. This is not one of those cases.
A static inline function will be indistinguishable from a macro in terms of the code generated by any decent compiler and is generally preferred.
|
|
|
|
|
geoffs wrote: A static inline function will be indistinguishable from a macro in terms of the code generated
Not necessarily true. A macro will always be expanded by the preprocessor, and the code compiled as is. An inline function will only be inlined if the compiler thinks it's a good idea (for example it might be if you are optimising for speed, it may not be if you are optimising for size). Don't forget inline is a request to the compiler, not a command. It can leave the code as a function if it wants to.
A macro forces the issue - a function leaves it to the compiler to decide.
|
|
|
|
|
Although this is getting away from the original intent of my posting, you are correct that inline is merely a request to the compiler. For all intensive purposes, in most cases, a simple function as shown will be inlined by the compiler. There will be exceptions to that case.
|
|
|
|
|
That's why I put the smiley.
geoffs wrote: intensive purposes
intents and purposes
|
|
|
|
|
PIEBALDconsult wrote: intents and purposes
Thanks for that correction!
|
|
|
|
|
WTF !!! macros are gold the end.
|
|
|
|
|
"As it's C++, define a macro."
That's a horror in itself. C++ provides inline functions that would do the same job much better. Indeed, the potential pitfalls of the C preprocessor are one of the main motivations for this feature.
|
|
|
|
|
The language provides that feature?
|
|
|
|
|
How is the static_cast better than a normal cast in this case?
David
|
|
|
|
|
Depends on what you mean by a "normal" cast...
1. If you mean a C-style cast (ie: (uint32) <something> ), then my answer would be that the code is C++ and the correct thing to do is to use the new style casts provided by the C++ language. They are there for a good reason.
2. If you mean, why did I not just allow implicit casting to uint32 by the compiler, it's because assigning a double value to an unsigned long produces a warning message ('possible loss of data') depending on the warning level set for the compilation. Since I compile at the higher warning levels and will see the warning, and have a policy of not allowing warnings from my code, I do the explicit cast.
The issues I touched on above are very well described and explained at this site: C++ FAQ Lite. This is a great site for beginners and seasoned c++ programmers.
|
|
|
|
|
Been refactoring some of my code and stumbled upon this.
string XMLCommand = "<<Command Name=\"DoStuff\" ID=\"";
XMLCommand += ID.ToString();
XMLCommand += "\"/>";
The double << are necessary or the site wouldn't display all code (why actually? It shouldn't be any valid HTML tag).
I know, I should use the proper XML classes but I've been too lazy, especially cause 3 lines below it, I'd need to convert it to a string anyway (to send it with a StreamWriter).
|
|
|
|
|
Yes, for a number of reasons including the concatenation of strings.
I suggest you use something more like
string XMLCommand = string.Format
(
"<<Command Name=\"DoStuff\" ID=\"{0}\"/>"
,
ID
) ;
But that still doesn't explain the extra less-than; you should find out what the problem is.
|
|
|
|
|
PIEBALDconsult wrote: string XMLCommand = string.Format
What is string.Format?
PIEBALDconsult wrote: But that still doesn't explain the extra less-than; you should find out what the problem is.
I explained in in my first post already, it's because CodeProject only displays half the code without it.
s_mon wrote: XmlDocument xmlDocument = new XmlDocument();
xmlDocument.AppendChild = xmlDocument.CreateElement("evil");
I know, I know.
I wrote the code before knowing any XML classes and just been too lazy to change it now.
Also, I don't think it's necessary to create a new XMLDoc and append an element and Attribute just so I'll pass the OuterXml to the send method anyway.
It's quick & dirty but it does it's job and for a single line of XML I think it's ok.
I use the proper classes when building larger XML.
|
|
|
|
|
Ohhh... so that's what you meant by "the site wouldn't display all code", I had assumed you meant some site you were working on.
Try escaping the < with < (which is what the "Auto-encode HTML when pasting?" does.
|
|
|
|
|
Megidolaon wrote: It's quick & dirty but it does it's job and for a single line of XML I think it's ok.
That's what I thought until I was passed some text with values that needed to be encoded.
Like < and & and even a Ctrl-C 
I have since worked up a class to make it easier and hide the details.
|
|
|
|
|
Anything to do with XML is a coding horror
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
|
XmlDocument xmlDocument = new XmlDocument();
xmlDocument.AppendChild = xmlDocument.CreateElement("evil");
;o)
(yes|no|maybe)*
|
|
|
|
|
That's evil
Seriously, that is okay, I've seen worse
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
|
|
|
|
|
Megidolaon wrote:
<big>string</big> <small>XMLCommand = "<<Command Name=\"DoStuff\" ID=\""</small><big>;</big>
<small>XMLCommand</small> <big>+=</big> <small>ID.ToString()</small><big>;</big>
<small>XMLCommand</small> <big>+=</big> <small>"\"/>"</small><big>;</big>
My eyes! The goggles do nothing!
-Spacix
All your skynet questions[ ^] belong to solved
I dislike the black-and-white voting system on questions/answers. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
