If you've been programming for a while, you've probably seen your fair share of weird code. Much of that weird code is just plain bad; it isn't obvious, it's undocumented and it makes the person maintaining it thing "what the hell were they thinking?" Eventually you learn software rarely emerges fully formed from some heroic programmer's forehead. It's a collection of hacks layered on top of each other (most applied at 3AM after your system goes down.)
However… there are a number of constructions I've come across that appeared strange at first, but then later turned out to embody non-obvious wisdom.
This is an attempt to catalog a few of these patterns. You don't have to use them. You don't have to agree with them. But it might be worth learning about them so you'll know more about what the original author was thinking.
When comparing a variable with a literal value, most programmers put the variable first and the literal value second, creating code that looks like this:
if( pointer == NULL ) {
/* do something */
}
But sometimes you'll run across code where this is reversed and it looks like this:
if( NULL == pointer ) {
/* do something */
}
It turns out there's a decent reason to do this. Click over to Literal Comes First in a Comparison to learn more.
The debate about GOTOs has been raging for decades. Most people agree, GOTOs are bad. Programmers should use structured programming features: loops, class dispatch, switch statements and nested if's.
Used sparingly, GOTOs can be used to quickly exit the middle of a routine on an error condition. This comes up in Plain ol' C where you can't use or if you're using Async I/O.
There is an alternative, however. See Avoiding Gotos by Using Do...While Loops for more details.
Modern languages don't think a trailing comma in an array definition is an error. Even C doesn't complain about trailing commas anymore. But every now and again you'll see someone who separates elements in an array with a comma at the beginning of a line, like this:
char *items[] = {
"one"
, "two"
, "three"
}
There's a reason people used to do this. Read more at Commas at the Beginnings of Lines.
You would think with decades of experience converting integers to strings, humanity could come up with an elegant syntax and semantics regarding type mutation. But you would probably be wrong. Language designers more often than not pick syntax and semantics for convenience, not purity. And that's probably okay.
But it does mean that weird things happen when converting between strings and integral types, especially in dynamic "scripting" languages like JavaScript or PHP. Check out Number and String Mutation to see how funky code can get when dealing with type conversion in dynamic languages.
Every now and again, you'll see a for loop where the end condition is set as a variable in the loop initialization clause, like this JavaScript fragment:
var a = [ "one", "two", "three" ];
for( var i = 0, il = a.length; i < il; i++ ) {
console.log( a[i] );
}
Why would a programmer do this when it's just as easy to do this?
for( var i = 0; i < a.length; i++ ) {
console.log( a[i] );
}
The answer has to do with inefficient JavaScript implementations, C programming and inertia. Learn more by reading Explicit End Indexes in For Loops.