If you write code for a living, you don't have to be around very long before the subject of coding standards comes up, and it is a subject about which people tend to have very strong opinions. My own very strong opinion is that most so-called standards really are styles, and that they do not rise to the same level as standards. How many spaces you use to indent a line of code is a style (or do you use tabs?); whether your code compiles when you don't have a trailing semicolon is a standard.
Call me pedantic (you wouldn't be the first) but I think the distinction is important. When people are discussing the formatting of any given piece of code, it is easier for the proponent of a certain style (opening curly braces, for example) to get his way if he can appeal to the authority of the "standard" to support his position (reference to the logical fallacy fully intentional). Just because that person was pushy enough to get his way codified doesn't make it right, though.
Countless hours have been spent discussing, drafting, arguing about, and then conforming code to some standard or another, and that's a sad waste of time. Worse, for me anyway, is that many coding standards make code harder to read, such as requiring comments on every method, requiring regions (collapsible blocks in which code lives in a code file) around every conceivable form of code in a file and in a certain order (sometimes even where there is nothing actually *in* the blocks, or when the block already has a collapsible region with a title!), and worst of all, requiring that something like a property getter or setter take up four lines of code when it could all fit on one.
Standards that don't help your code convey something important or interesting about the code should be eliminated, at least as far as what a coder has to deal with on a day-to-day basis. If stylized code makes it easier for the source control tool to diff and merge, well, require running it through a prettifier before committing changes. Just make sure the prettifier can reverse-engineer the code back to *my* way before I have to see it!
1 comment:
Agreed but you forgot the most important point: my style is the One True Style. (I know it is because Gandalf gave it to me.) Anything that deviates from my style is obviously, categorically, existentially wrong. If my style appears to have inconsistencies, it's just because you're not smart enough... Blah. Blah. Blah. ;)
I've lost much of my willingness to argue about style. (I'm still just as passionate, though.) For decades we have had perfectly useful code beautifiers but, for the most part, people haven't adopted them. I think that's partly because most version control systems have no support for pre-checkin and post-checkout triggers. But it's probably also due to the religious nature.
One of the advantages of Ada (or would that be "Adavantage"?) is that the code was stored in the DIANA tree. So, at least on the Rational R1000, each user could have their own format entirely independent of how the code was saved. Of course, that left more time for arguing about semantics. ;)
Post a Comment