Coding Conventions
by Peter Viscarola
As published in The NT Insider(tm) March-April 2003
Software engineers are some of the strangest people I know. That's not to say that there is one particular software engineer that is the strangest person I know. (It's actually a tie for that honor in my world, between Captain Don Stewart of Bonaire and one of my wife's friends who thinks that "sending out a message to the universe" is an effective method of birth-control - Or, I should say, she thought it would be effective. But I digress.). But as a class, software engineers easily take the award for weird.
Why do I say this? Well, have you ever met a software engineer that likes anybody else's code? You know, somebody who is truly detached and rational when it comes to the style of commenting, indenting, bracing or coding. Every dev thinks their coding style is right, and everyone else's coding style blows. Few people can even agree on really basic things. Are goto's bad? Should every function have one return point? Is exception handling, and raising exceptions for errors, a force for good or for evil?
And, of course, there's the C versus C++ debate... heck, I'm not even going there. Not even in a pontification.
Don't get me wrong. I'm not looking for a consensus from the entire universe of programmers. I'd be content if driver writers, no, sorry... I'd be content if just Windows driver writers were all on the same page about even some of these things. Say, if we could just all agree on whether or not the left curly brace gets indented or not. But, quite obviously, that's not going to happen. Particularly frightening is the fervor with which software engineers cling to their beliefs as the one true set of beliefs, and the lengths to which they will go to justify and defend them. These come dangerously close to madness. (I was going to say that it reminds me of Donald Rumsfeld. But I would never say that, because rude, disrespectful, non-patriotic, riot-inciting, talk like that these days in the United States could get you branded a terrorist, locked in a military prison without access to legal counsel, and probably eventually shipped off to a country with communistic universal health care and where they don't have freedom of speech like we do here. But I digress.)
I recently saw a posting on a mailing list where the author asked if Microsoft wouldn't mind re-formatting all the examples in the DDK to suit his preferred bracing and indentation style, so it would be easier for him to read. Seriously. To me, what's really annoying about this isn't that he asked Microsoft to do this - which is basically hosed, no doubt about it - but that I understand completely where he's coming from. It is really freakin' annoying to have to read code that's done in a style that's dissonant with your own. It just grates on you. When I'm studying a module that I didn't write, I often find myself unconsciously editing the file to change the brace styles to my own preferred style as I go. Even if the original file is read-only. It doesn't matter. I can't control myself.
Naturally, everybody has reasons why their style is best. The reasons why devs prefer one style over another are usually incredibly well thought out and eruditely and convincingly expressed. Examples of such arguments typically include "your style sucks", "your style is ugly", "I can't stand to look at that", and "your style is not mine."
I recently heard one software engineer declare that his programming style (very similar to GNU style) was best because it was based on principals of human psychology (he even cited references, which he urged people to read before replying). The worst thing about this is that this guy's far from ignorant, so he probably has a legitimately defensible position. Not that it matters of course. His programming style sucks, mainly because it's ugly, I can't stand to look at it, and it's not mine.
The only way to eliminate style debates are to make indenting and bracing styles part of the language. I recently made the mistake of learning Python, because I read somewhere that it was the up-and-coming modern replacement for Perl (and also, because if I didn't spend time learning Python, I would have to write my other articles for The NT Insider). In Python, there are no curly braces to act as "begin" and "end", and indenting is used to indicate the blocks. And (like C) it's case sensitive, so you don't have some people writing "PRINT" and others "print". Here's a sample Python script:
print "Here we go!"
cnt = 0
while cnt < 5:
if cnt<3:
print "cnt is less than 3. It's ",cnt
print "this is a useless message"
else:
print "not less than 3!"
cnt = cnt + 1
print "we're done now"
Terrific, huh? I mean, you have to read it with a freakin' ruler, but at least Python people don't have wars over braces. The only things left to argue about in Python are how many spaces should an indent be, and where to put blank lines and comments. But I've found that most people who write in Python don't spend any time arguing about these things. This is mainly because they spend all their time arguing with other people about whether Python is better than Perl.
It's interesting to see the clever and articulate arguments that they use to convince Perl programmers that Python is better. Basically, these arguments come down to four things: "Perl sucks", "Perl is ugly", "I can't stand to look at Perl", and "your language is not my Python."
Perhaps it's hopeless.
Copyright (c) 2003, OSR Open Systems Resources, Inc. Reprinted with permission.