The problem with #ifdef

December 25, 2006

Something that crystallized in the process of writing the earlier Bourne shell quoting entry is that #ifdef abuse leads to bad results for the same fundamental reason that multiple levels of escaping are bad: after a certain point, people can no longer clearly see what the real code will look like.

When you can't see what the code looks like, it's really hard to make sensible changes; either you make blind stabs or you have to carefully reconstruct the actual code, usually by hand. Either process is error prone, and it's easy to fool yourself, and you are effectively doing remote control programming (with mushy feedback).

Ironically I suspect that the really dangerous #ifdef'd code is not the code that is completely snarled up, but the code that is halfway there. Code that is a complete mess is clearly beyond understanding, but code that is only half-overgrown with #ifdefs tempts you into thinking that you can follow it when you actually can't.

(The worst #ifdef'd code that I've personally encountered and haven't frantically scrubbed out of my brain is the xterm code, which is a shining example of what not to do to make a portable program.)


Comments on this page:

From 66.243.153.70 at 2006-12-26 15:49:45:

How can a blog entry like this not mention http://www.literateprogramming.com/ifdefs.pdf

By cks at 2006-12-26 17:09:57:

"In computer science, we stand on each other's feet" -- Brian K. Reid.

(This is apparently an adaptation of an earlier version by Richard Hamming.)

Written on 25 December 2006.
« A thought of the day
Link: varnish, a HTTP accelerator »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Dec 25 23:48:25 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.