Binary Code

Over on Artima Developer in Style is Substance Ken Arnolds proposes, back in 2004, that language compilers should not only enforce syntactic correctness but also stylistic correctness:

…coding style is an essentially solved problem, and we ought to stop worrying about it. And to stop worrying about it will require worrying about it a lot first, because the only way to get from where we are to a place where we stop worrying about style is to enforce it as part of the language.

Yup. I’m really saying that. I’m saying that, for example, the next ANSI C update should define the standard K&R C programming style into the language grammar. Programs that use any new features should be required to be in K&R style or be rejected by the compiler as syntactically illegal.

I absolutely love this idea, unequivocally, unapologetically.

I’ve been hacking code for about thirteen years now and I can remember back when defining my own “style” was fun and interesting and made me feel l337. That was also about the same time I thought naming all the variables after chocolate bars was a clever idea and comments were for sissies - my code was so good I wouldn’t ever need to go back into it (”experience” is understanding the difference between “won’t” and “can’t” before it happens).

Fortunately for me those heady days ended about twelve years and six months ago when I realized that my code didn’t look like most other code and I was spending an inordinate amount of time reformatting the world’s code to suit mine. Turns out it’s a hell of a lot simpler to reformat my code to suit the world. Go figure.

We programmers don’t write prose. We don’t write poetry. Admittedly we like to think we’re artists but the truth is what we write is foundations and building blocks and lots of other euphemisms from the construction industry that we like to use when describing software. Coincidence that construction standards are so incredibly rigid? I think not. (Coincidence that construction standards are also called “code”, as in “this wiring is not up to code”? I also think not.) We don’t want our electricians getting fancy with the wiring and laying out their own colour combinations - white is neutral and green is ground - so why do so with computer code?

White wires connect to white wires. Look at a circuit with white going to black and though the light may be on and everything works jim-dandy that circuit just looks wrong. Feels wrong. Worryingly wrong. Stay awake at night wondering about the quality of all the wiring in the house wrong.

As most good programmers will attest awkward but functional code tends to feel the same way. There’s even a term for it: code smell, though the term doesn’t fit with my touchy-feely metaphor anymore… but I digress. Unlike with wiring there’s no need to change bad-looking code. In fact if the code works the most common course is often to ignore it, hope it goes away, pretend it’s a black box function in the bad way, not the good way. There’s always more code that needs writing and if it works, it works right?

The beauty of making language style a condition of correctness is that it is not punitive. All code already has a style, consciously derived by the developer or not. All this would do is make that style uniform. Just one style so we’re all playing by the same syntactic rules. Let’s leave the free-form stuff for linguistic languages where the creativity is desirable, a plus, and start making

if(x<y)
    {

illegal.

If not for us, for those who’ll come after, so they don’t lay awake at night wondering if the house is going to burn down.