Joel on Software: Making Wrong Code Look Wrong. ⇒
11 May 2005, early afternoon
Interesting advice on coding standards.
This is a post from my link log: If you click the title of this post you will be taken the web page I am discussing.
11 May 2005, early afternoon
Interesting advice on coding standards.
This is a post from my link log: If you click the title of this post you will be taken the web page I am discussing.
Interesting read. A couple quick thoughts that came to mind.
(1) XSS is evil. I’ll have to remember that.
(2) Why let your eyes (i.e. brain to all the work? Maybe you shouild just make a safeString class and dump (a good chunk) of the work onto the compiler. (Recall that automating tedious, repetitive tasks are one of the things computers are good at).
(3) Man, doesn’t Hungarian notation make source code look like CODE, or what? (i.e. Who the hell is going to know what a _fpxusiValue is suppose to represent?)
by Ryan on May 12 2005, 6:27 am #
Well said Ryan. Although I think he’s trying to discuss elements of a program that aren’t easily captured by a compiler, I don’t think the examples he brings up are particularly good. As you mentioned, I am sure you could write some sort of safeString class with relative ease.
His example of rwThis and colThat used in Excel programs to differentiate rows and columns is also a little silly, since this could also be caught by the compiler if the types of the variables were made distinct. If columns and rows aren’t supposed to be mixed together, than one should explicitly say so. In ADA you could define a new type that is simply an integer with a different name. In ADA you could assign different semantic meaning to variables that hold the exact same sort of data. (It’s a shame typedefs are treated as synonyms in C++.) In C++ with templates I’m sure you could create a generic row variable, and a generic column variable. One that is strictly type-checked, but would behave like a normal integer. I thought it was a bit disingenuous that he brings up the follies of operator overloading without explaining why it is useful.
If you keep your notation short, I can see why it would be handy to have a little shorthand at the start of each variable letting you know what the variable is supposed to do. But to consistently remember to use this notation seems something that could be quite error prone. Just like how comments in code can quickly get out of date, I could see variable names getting out of date in the same way. If you were writing C code, or something in a language that offer very weak type-checking, a notation like this is handy. With modern languages and tools, I think it’s really not needed.
by ramanan on May 12 2005, 12:57 pm #
Yeah…C/C++ gives you enough rope to hang yourself. If you want to overload operator=, operator*, etc. to mean weird things instead of using meaningful method names then, yes, it has the potential (likelihood?) of screwing you. But, overloading things like operator==, operator<<, etc. seem quite useful.
What if you make a class like this:
class Column {
private:
unsigned int _value;
public:
explicit Column( unsigned int value ) : _value( value ) {}
inline
Column
operator+( const Column & that ) { return ( this->_value + that.value ); }
// etc.
}
and inline all your methods then use compiler optimization? Would your efficiency end up close to what it would if you used primitive types directly?
by Ryan on May 13 2005, 2:23 am #