When standards become straitjackets

I am not a fan of the proliferation of coding standards. Don’t get me wrong: they have their uses. Database collation, ANSI settings, file locations, security practices: these are all sensible candidates for enterprise-level rules. But telling me that I must – not should, but must – capitalize my SQL keywords based on nothing more than someone’s unsupported (and unsupportable) contention that doing so somehow makes SQL code more readable is going beyond the pale. Likewise the assertion, once put forth by a colleague, that that which is not in the standard is eo ipso proscribed, and has no business appearing in one’s code.

All this is not to say that there are not preferred ways of doing things. Rather, if you’re going to say, “Do this, and don’t do that”, then you ought to have good reason for doing so, and those reasons ought to be enumerated, and backed up by demonstrable fact and reproducible evidence. Otherwise the standards seem capricious: do it this way because management says so.

I’ve heard the argument made that capriciousness is a necessary evil: that developers, particularly those whose careers are in their infancy, need the guidance of hard and fast rules so that they can contribute quickly to the team. Poppycock. We’re not talking about high school grads signing up for an apprenticeship: we’re talking about people who have completed four year degrees at accredited institutions of higher learning, or at the very least a two-year or three-year technical program. We’re talking about people with a demonstrated capacity to learn, and at least an above-average interest in exploring technical subjects. It’s condescending to assume they can’t understand why specifying the column names in a SELECT list is better than using the wildcard “*”, or why parameter sniffing can sometimes get you in trouble. Demonstrate, illustrate, illuminate: in a word, teach: don’t just dictate.

The worst offenders, I think, are standards that dictate not what your code does, but how it looks. Stylistic variations are condemned as apostasy; conformity for conformity’s sake is the goal. Do I care if you prefer “SELECT” to “select”, or vice versa? I do not. Nor do I care if you place your commas in front of or behind the column names, nor if you use “AS” before your aliases, nor if you put the joined table name on the same line as your join or on the next. I care that you know what an execution plan is, and how to read it, not that your code is symmetrical and aesthetically pleasing. I care that you put some effort into crafting that index, not what you named it.

Standards, carefully considered and properly administered, insure compatibility between databases, servers, and applications. Created reflexively and indiscriminately, they are the developing world’s equivalent of teaching a pig to sing: you will only frustrate yourself, and piss off the pig.

Advertisements

About bigpurr

Pursuer of knowledge, maker of music and poetry, bird watcher, cat lover, maven of literature and fine beer, and champion of reason...
This entry was posted in SQL Server Development and tagged . Bookmark the permalink.

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