Six Tips For Fewer Bugs

By David Berube

Conduct creative code reviews.

Code reviews can be formal or informal, and they can be great even if you're a single-person team. You can have great success reading code printouts in all sorts of odd situations - in the pool, at the beach. Give it a shot. Try using markers and hacking the printouts all up. Try pasting all your code on the walls of a room, and assign a section of a wall to each team member.

Keep your variable names up to date.

It's easy to let variable usage drift over time. A variable starts doing X, but changes over time, and eventually it doesn't have anything to do with X. This is very dangerous - it'd be better to name that variable TEMP or something nondescriptive, because at least then we wouldn't have any wrong ideas. If a variable name is off, we can end up with some very nasty bugs. Rename variables when they drift.

Use lint or equivalent.

Lint is your friend, and it's very smart. If you language supports it or an equivalent tool, use it. Lint may seem annoying at first, but all it's warnings have reasons - if you can eminate as many of them as possible, you'll code will be vastly improved. (You can't always get your code lint free - believe me, I've tried.)

Many languages that don't support nt still have similar compiler/interpreter warnings - often, you can turn on a higher warning mode. If so, turn all the warning options up to max, and pay attention.

Use automated testing, and make sure it works.

If you aren't already use automated testing, start now. Make sure that you aren't doing it just so that you "do automated testing", too - be sure to integrate it with your development. If you find a bug, implement a test to detect that bug - that way you can be completely confident that bug, or a similar one, doesn't exist, even after you make significant changes.

If it is annoying, reimplement.

It's tempting to just ignore problem areas. Don't. If a particular section of code, whether it be large or small, bugs you, fix it. The buggiest, nastiest sections of code are the parts that need the most work. If you are reworking the worse sections of code, it's amazing how quickly the quality of the overall project increases.

Never apologize - fix it instead!

Comments should not apologize for problems except in the most dire of circumstances. If it's bad enough that it needs explaining, fix it so that it's obvious. There are exceptions - sometimes, for performance reasons, readability is sacrificed. Sometimes there isn't any other way. Never apologize in a comment out of laziness, though - just fix it!

Copyright 2010. Berube Consulting. All Rights Reserved.
Call anytime, (603) 574-4766. Outside of the USA, dial +1 (603) 574-4766.