So you followed all my tips in the first installment, but you’re still worried that your code might be maintainable? Here are some more:
- Forced to fix a bug? Don’t worry, you can reintroduce it a couple of releases later, as long as you remembered not to add a regression test for it.
- If you must document code, don’t take the opportunity to explain WHY it’s doing what it’s doing. Just describe the obvious. Learn from the masters at Microsoft:
// Initialize the column to '0' ColumnToSort = 0; // Initialize the sort order to 'none' OrderOfSort = SortOrder.None;
No, really, that’s not made up – see for yourself.
- If you have to generate a lengthy SQL statement, avoid any kind of formatting of the code that might make it readable. Instead, cram it all on one line such that you can only see a small part of it at once.
- Avoid unnecessary timezone calculations by living on the Greenwich Meridian and only testing your code when DST is not in effect. Or preferably not at all.
- Threading is your friend. Find obscure ways to make sure your functions are not re-entrant. When reports of random failures come in from production environments, simply say you can’t reproduce them.
- Carefully read any coding standards that apply to your project and commit them to memory – otherwise there is a risk you might comply with part of them by mistake.
- A multidimensional array is a fine construct for storing your tabular data, but only if you refer to all your columns by numbers and don’t document them. Better still though, is a comma-separated list of pipe-delimited strings. For bonus points, use a delimiter that only rarely occurs in the actual data.
- Use floating point numbers for your currency calculations.
- Although cluttering up the code is normally a worthy cause, don’t waste your time validating user input. Rely on bug reports to find out the interesting effects of the ‘unexpected’ things they entered.
- Refactor. Because you feel like it.
