Save Me from Cleverness

Programming guru Brian Kernighan has famously said that debugging code is twice as difficult as writing it—and, he said, it follows that, "If you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." Id generalize this to two principles that should be followed by anyone who buys, builds or uses complex and powerful systems: Leave half of what you have in reserve, and assume below-average cleverness.

I first saw Kernighans warning in the 1988 paperback reprint of his 1974 McGraw-Hill book (with P.J. Plauger), "The Elements of Programming Style." Many people have been quoting his comments this May in the context of a flaw found in March in a widely used implementation of the X Window System, an MIT-originated protocol for cross-platform GUI construction.

Despite the mocking label of "the first fully modular software disaster" seen on a poster at one X Window conference, X Window has been a pathway to portability for any number of useful tools that might otherwise be available only on Windows. For example, the Macintosh version of the SlickEdit programmers editor runs on Macs by means of the X Window implementation packaged with OS X.

X Window is an open-source project (www.x.org), with plenty of eyes scanning its reference implementation and other implementations for bugs or vulnerabilities. A Department of Homeland Security audit (your tax dollars at work) found the flaw that provoked this months comments on cleverness—and many have since made the point that this demonstrates a key virtue of open-source efforts.

In our own eWeek story on how the vulnerability came to light (see "Govt-funded security audit flags X11 vulnerability" at eweek.com), the chief technical officer of the DHS contractor doing the audit described the cause as "something as seemingly harmless as a missing closing parenthesis." Thats not quite correct, and the problem would have been found much sooner if that had been the case.

Missing punctuation will generally result in a programs failing to compile, let alone run—although substituting one punctuation mark for another can be devastating, as in the legendary case of the FORTRAN code that disrupted a NASA mission when a period replaced a comma.

In the case of the recently discovered X Window flaw, the missing marks were a pair of parentheses, creating a classic case of the machine doing exactly what it was told instead of what was wanted. In two places where the code should have said "geteuid()" (call function "geteuid" with no arguments and return the result), there instead appeared "geteuid" (return the memory location of the "geteuid" code).

The error would have been caught if the C programming language distinguished between the concepts of zero (a number) and null (absence of a value), but it does not. The convenience of using "0" for both, and the cleverness of letting a functions name serve as both verb of invocation and noun of code location, are defining features of the C language—of which cleverness critic Kernighan, ironically, was one of the main designers.

Famously terse, C is not a language where youd expect to find something as verbose as Visual Basic .Nets "AddressOf" operator, which appears in statements such as "AddHandler Button1.Click, AddressOf Button-ClickHandler" (an example from Microsoft documentation) and makes the codes intention perfectly obvious. Another good rule to remember is that most code will be written only once but read many times, and that its more important for a language to be easy to read without ambiguity than to be easy to write with few keystrokes.

But coders are not the only ones who are ill-served by systems designed to treat almost every possible input as a legitimate (if, perhaps, obscure) command. Try to find a keystroke in an application like Microsoft Word that doesnt have some function, changing the editing sessions behavior without telling the user how or why.

Real systems and real users dont do well when balanced on the sharp edge of making too many things too easy to do, in ways that are often too difficult to see.

Peter Coffee can be reached at peter_coffee@ziffdavis.com.

For reader response to this column, click here.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.