Programming Proverbs 15: Avoid tricks
Tricks are fun. It is often pretty satisfying to add a bit of code that is tricky, difficult or perhaps something that not everyone is going to understand. Well it's fun when it is done but later when the code has to be changed, modified, or worse - debugged its not always so much fun.
Tricks often work because they take advantage of ambiguity or implementation inconsistencies. or they rely on some deep understanding of low level details. The problem comes into play when those features change. For example a trick that takes advantage of overflows in a 16 bit word will break when the application moves to a 32 bit computer. Or a trick that takes advantage of a loop checking a value at the bottom even though the specification calls for it to be checked at the top of the loop will fail when a compiler that correctly implements the specification comes out. I actually know of cases where that latter problem happened!
There is a reason things are called tricks after all.
Tricks also make maintaining and debugging more difficult. Programmers really need to think about the person who will maintain their code. Most coding happens to existing code that someone else has written. If the next programmer doesn't know the trick they may very well have trouble working with your code.
Of course if you can't avoid using a trick at least comment it well. Explain it in detail so the next programmer to look at it will have a fighting chance to figure it out.
This is the fifteenth in a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
