I'm surely like you in my deep appreciation of my own particular coding style. My style was all over the map until I started writing code for publication years ago. At that time (as it remains today), C was the sort of language with lots of competing styles. There was K&R style, which never appealed to me, and then just about anything else that would compile. Some people developed a style based on aesthetics, others on readability, and others yet — the crowd that writes if( 4 ==y ) in the quixotic belief that style can improve correctness. My personal style evolved as it did because I was publishing my own little C magazine and I wanted the code to be as legible as possible when printed in a small, monospace font. So I used lots of vertical space and put whitespace around operators and used lots of parentheses. Even today, code I wrote long ago is easy to read in print. The same is true about my Java style. My C coding style carried over and was modified as necessary. It too looks great in print…to me, at least.

At many sites I worked at, I participated in long, rather boring conversations about what good style is or should be. Like you, I've seen developers rant about being forced to adopt conventions that offended their particular sense of how syntax and semantics should align. My feeling in all these conversations, even years ago, was that I was babysitting adults. The core debates are invariably about the use of optional characters, the placement of braces, the indenting of code blocks, the amount of white space, the form of comments, and trivialities like the order of include statements. Given the wealth of details, any sane combination of preferences is unlikely to provide much lift over a competing set of choices. It just isn't worth arguing about. Yet programming forum articles on tabs vs. spaces still get dozens of comments.

What is an important problem, though, is the use of many different styles at one site under the theory that programmers should be allowed to do what they're most comfortable with. This choice leads to several problems. The first is that some programmers have truly odd ideas about coding style. The second is that by having multiple styles in one code base, the code is difficult to read, especially if it's been maintained by several developers. The final reason is that many developers will reorganize blocks of code to their preferred style when doing maintenance and then check the code in. This step means that all kinds of meaningless deltas are generated by the check in, causing lost time and confusion down the road.

Sites are right in choosing and enforcing a single coding style. It's more important that they stick to the style than what the style is. However, with no two sites using the same style, there is still time lost by new developers joining the team. An optimal solution in my view is to have the language designers enforce as much of the style as possible. This approach would greatly facilitate reading and writing code. Language designers have been slowly recognizing the benefits of this. In the early days of languages, anarchy ruled. I've mentioned C, but Fortran was even wilder, as it did not even require white space after keywords! This allowed all forms of truly terrible code to be written and handed down to unfortunate maintainers for decades.

In more recent times, though, languages have tightened up. Python has strict indentation rules to signal blocks of code that go together. Go, the emerging systems language from Google, has coercively addressed the placement of opening braces: They cannot be the first character on the new line. In a sense, the question of opening braces in Go has been resolved in favor of the K&R style. Importantly, Python developers don't complain about the indentation requirement, nor do nascent Go programmers complain about the braces positioning.

This acceptance suggests that perhaps the community is getting wiser — recognizing the benefits of style uniformity as well as the costs of multiple differing styles. Pursuing this thread, I would argue that language designers should go much farther in this direction. As code bases grow ever larger — the 10 million lines in our lead feature this week are by no means an exceptionally large number — the value of having a uniform style enforced by the compiler enhances readability and removes a nagging issue that should have been solved long ago. I, for one, would happily ditch the style I've used for years to meet other developers in a single, readable, mandated approach to code.

(Additional note: I am certainly not the first person to propose this idea. In 2004, Ken Arnold of UNIX fame, wrote a humorous essay on the topic that was later selected by Joel Spolsky in his 2005 anthology of the best writing on software development.)

— Andrew Binstock
Editor in Chief
alb@drdobbs.com
Twitter: platypusguy