You’re buying a house, and there are two prospects that different builders have asked you to look at. You want to make sure that both houses are up to code, are livable, and that you’ll be able to make repairs when the inevitable maintenance issues come up.

House A is pretty typical; the walls are in great shape, the rooms flow well into each other, the paint is evenly applied applied, and the light switches are in places you expect them to be. The appliances all seem to work. The builder has all construction records, and when you ask about why something was done a particular way he either refers you to a section of the building code or gives you a well considered reason.

The builder of house B had different ideas. The wallboard is not well taped, there are holes in walls, there are many patches of missed paint, and there is no moulding anywhere. The rooms are oddly placed (two bedrooms open off the kitchen, and the kitchen only has a door to the outside). All the light switches are located in a closet near the front door (“for convenience,” says the developer). The washer-dryer is in the kitchen, the refrigerator is in the master bedroom, and you think that the dishwasher might be accessible through the crawlspace. The plans for the house exist as crabbed scribbles on a Big Chief pad (“somewhere, where did I put that?”), and when you ask why something was done a certain way you get an answer along the lines of a shrug and an “I don’t know,” or worse, “It doesn’t matter, it works, doesn’t it?”


“But brace style doesn’t matter,” protested the engineer. “You guys all said that at the beginnging of the project.”

And so we did. But, “Dennis Ritchie can get away with it, but you can’t” is what I should have said in the last really bad code review I did. The train-wreck had started months earlier when the engineer in question had refused to write his components in the same language that the rest of the team was using. This is a Bad Thing — really a management issue — and it got much, much worse. (One of the worst situations you can be in is to discover a very buggy piece of code just before you ship; your choice is to either spend N hours fixing it, or the same N hours re-writing it, and management will never risk that much new code that late in the game, so you’re stuck with it; you get to spend probably N hours fixing it, several more multiples of N maintaining it over the next several releases, and then you might arrange a rewrite. In your spare time).

Of course, you had an inkling that there would be trouble, because the code looked “kind of messy.” Listen to the alarm bells; this is your early warning system kicking in.

Honestly, there are levels at which it doesn’t matter how code is formatted. The compiler certainly doesn’t care. Seasoned professionals can go into anything: random brace style, goofball indentations, a wacky circus of macros, you name it and we can deal with it. That doesn’t mean that we like it, or that it should be permitted to exist. Function follows formatting; as a rule of thumb, messy-looking code has the most problems, is the most likely to be coded to brittle assumptions, and is the most difficult to modify when (when) problems show up.

It’s embarassing, but a frequent answer to the bitter question “Who wrote this crap?” is often “You did.” Meaning that even well-designed and written code written by yourself will be opaque and pretty junky six months later. At a style level, you are not coding for you. You are coding for the next poor schmuck to come along and fix your bugs. Have pity; that poor schmuck is likely to be you, and if it’s not . . . well, leaving a decent legacy behind you is always good practice.

Engineers get bug-eyed and start breathing rapidly when I start ticking off items like putting spaces after commas and around operators, having a consistent naming style for variables, giving each variable its own separate declaration and so on. The minutia of coding style at this level seems to be beneath people, especially (it seems) the junior engineers. They bristle at this kind of treatment. But if you look at the really good coders, the ones who pound out thousands of lines of really good stuff a week, you’ll see that they do pay attention to this kind of thing (and many, many other details, like decent unit tests and documentation, and things that are way above style).

Style is where things start; would you subscribe to a magazine with mispelled words and badly formatted paragraphs? What do errors or uncaring at the lowest levels imply about the higher level content?

Like I said if you’re K or R, you can write any way you want. But if you’re a couple years out of school and God’s gift to the profession of programming, style is not beneath you, and it’s worthwhile taking a look at what the experts are doing.

Next: A diatribe on the naming of names.

This entry was posted in Uncategorized. Bookmark the permalink.

0 Responses to Style

  1. Steve says:


    The CTO at my current gig does not subscribe to this viewpoint, as he regularly goes into my code, whose style I am rather picky about, and fails to follow any of it. There are hardly any extraneous spaces and his braces are opposite of what the rest of the file uses. Needless to say, I have a rather low opinion of his abilities.

    I can be pretty easy-going about bracing, but please, really, be consistent above all else!

  2. Jim E Tayler says:

    Where can I follow up for more information