It's hard to remember to do simple code inspections--the oldest quality technique in the software field--amid the welter of graphical tools, measurement tools, and other fancy tricks the industry has thought up. Code inspections make sense. If you find a flaw during a program run and debug it, you've fixed just one bug. Only a code inspection can fix the potentially hundreds of other similar bugs.

But code inspections are a headache, because logic and consistency are hard to determine. Miska Hiltunen is trying to make them more agreeable by rigidly limiting what you have to look for, and assuring developers that they can get through each inspection in just about an hour. His Tick-the-Code site lists extremely simple things that pop out of poorly constructed code right away, and that supposedly warn you of the risk of deeper problems. Things to look for include unchecked parameters, deeply nested structures, duplicate code, unnecessary comments, unfinished code, and poorly named variables.

How is this relevant to Beautiful Code? A chapter in that book by Laura Wingerd and Christopher Seiwald of Perforce focuses our attention on just such superficial aspects of source code. Simply lining up the code for different cases to show their similarities and differences, these authors claim, can prevent associated bugs. They show how a violation at one stage of one of their principles--deep nesting of control structures, which they, like Hiltunen, try to avoid--coincided with a sharp uptick in errors.

Will Hiltunen's list of simple rules help programmers avoid real bugs? Or is it a focus on trivia that distracts programmers from dealing with real problems in their design and algorithms? Testing and time will tell.

Perhaps we can look at the endeavor this way: design and algorithms are certainly the most important drivers of quality and good performance. But design mostly takes place outside of and before coding, while algorithms are coded by experts who provide them to the rest of us in packages. Most of us who code are cobbling together small programs with lots of glue from standard libraries. Checking for trivial coding inconsistencies may uncover a lot of the problems we need to find.