Enforcing coding conventions

It’s Black Friday which means that in most of the United States people are out shopping taking the advantage of supposedly great deals. I’m not indulging because I try to only buy stuff when I absolutely need instead of getting something just because it’s cheap. However the one thing that I did buy was the Kindle edition of the Joel Spolsky edited “The Best Software Writing”. It’s a collection of talks and articles about software. I could probably have gotten all the material for free online, but I decided to pay the $9.99 to actually get the Kindle edition. It’s the first actual Kindle book that I bought and I spent a good hour today reading it.

The very first article in the collection is “Style is Substance” by Ken Arnold. It is a suggestion to do away with differing coding formats and conventions in programming languages and instead having a single style for the language that is written into the language’s grammar. Thus if you write a program that violates the format rules, it’s not just ugly or bad form — it’s actually an incorrect program that will not compile. The suggestion is probably not a very popular one. In particular, programmers tend to be rather defensive about these sort of personal preferences — coding style, editor, version control tool, all have been know to trigger religious wars (and still often do).

Personally, I can understand the lure of having a single, undisputed code format that is enforced by the compiler. No more spending time figuring out where one block ends and another begins. No more spending precious mental cycles figuring out someone else’s conventions. One of the reasons I like Python is that it’s such a clean, yet flexible language. But on the flip side, I’ve generally been a fan of letting programmers use whatever tools they like as long as they get the job done. From that perspective, coding convention is just another tool and people should be allowed to use whatever one makes them work better.

However, the argument that code formats are just another personal preference doesn’t really hold up. In particular, unlike editor color schemes or other such preferences, code is something that is meant to be shared with other people. One of the greatest lessons I’ve learned from SICP is that programs must be written primarily for people to read and only incidentally for computers to execute. Since code will be shared, it makes sense to take measures that ensure that it will easily readable and comprehensible by other people. Having different coding is less like everyone using a different editor and more like everyone using a different XML schema to exchange documents. OK, it’s not quite so extreme, but it can be close.

If you’re someone writing a compiler or a language and you decide to enforce a single format, the next question is: which one? I would say for current popular languages like C, C++ or Java trying to answer such a question is a futile effort. It’s not that you couldn’t change a compiler to implement a particular style. The problem is rather that there are already too many conventions in place and you’d have civil war if anyone tried to enforce a particular format at the compiler level. If we are to take the idea of a single correct format seriously, it has to be implemented in a new, or at least not-completely-mainstream language. Haskell already has whitespace indentation built into the language. Instead of using curly braces to enclose statements in a function definition, you can use indentation in a manner similar to Python. This is built into syntax and violating the indentation rules will cause the compiler to fail.

Go takes a different approach. Instead of writing format rules into the grammar and compiler, there is a program called Gofmt which will reformat any syntactically correct Go format into the standard Go format. It can also be used as a syntax translator meaning that as the Go language changes, Gofmt can be used to automatically upgrade programs written in an older version of Go to a newer version as long as the changes can be described as syntax transformation rules. Gofmt is a powerful program and sets a high standard for language and developer oriented tools.

So will the languages of the features have strict formatting that minimize the amount the time we waste mentally translating between formats? Maybe. But I doubt that it will be considered a standard part of mainstream languages any time soon. While we have curly brace languages people will continue to expect that the various conventions of the current curly brace languages will also be applicable. Stylistically different languages like Haskell (and to some extent Go) will probably lead the way in changing the way we think of conventions and programming style. It’s interesting and a bit intimidating to see how far the bar for new programming languages has been raised in recent years, but that’s a topic for another blog post.


Published by

Shrutarshi Basu

Programmer, writer and engineer, currently working out of Cornell University in Ithaca, New York.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s