Wandering Thoughts archives

Why I don't like inverted if conditionals

Perl has an often used feature where you can write a conditional statement in a form like:

statement if (condition);

(You can use unless too.)

I find this usage lurching because it's a dislocation in my flow of thought. I start out reading the code thinking that the statement always happens; then I get to the if and whoops, time to backtrack on my understanding.

The worst form of this is when the if is indented a lot, so it's almost flush right with a lot of whitespace between it and the main statement. My eyes and mind have been carefully trained to expect that things hanging out by their lonesome in the right margin will be comments, not code that affects the program flow.

(At one point I actually wrote Perl code that looked like this. I tell myself that I know better now, but I'm probably doing equally heinous things somewhere else. Reading your old code can be a very humbling experience.)

Perl is not the only language that does this (there's Ruby, for example, and Python 2.5's conditional expressions also work this way). While Perl is the only one of them I currently have direct experience with, I don't think I'm going to like this any better in another language, Python included.

Thinking about types of bugs (and static analysis)

Someone from Coverity recently gave a talk to the local Unix hacks group about their static analysis tools, and in the process got me to thinking about the different types of bugs that I see.

As a first approximation, I think that I can split relatively common bugs into three different classes:

• mistakes like using the wrong variable or off by one errors.
• oversights like forgetting to free memory or unlock a lock under some circumstances.
• logic errors, where the code is accurately expressing your desire and you got all the details right, it's just you're doing the wrong thing.

(As always, the boundaries between classes can be fuzzy.)

Simple static analysis can find mistakes and straightforward oversights. More sophisticated analysis (on the level of Coverity's tools and the Linux kernel tool sparse) can pick up more oversights, although some involve sufficiently dynamic stuff that they can only be spotted through runtime analysis.

I think that true logic errors can generally not be caught by an analysis program, partly by definition. At best an analysis program might be able to determine that what the code is doing is nonsensical or pointless. To do better we would need some way of telling the static analysis program what the code should be doing, which is basically an unsolved problem.

(Tests, unit and otherwise, are one form of mapping out what the code should be doing. Given that some code is very difficult to unit test, I can imagine a static analysis tool for checking test cases in various ways.)