Grant Fritchey has a blog post about naming standards, including an excerable tblDdltbl. The comments thread then becomes people defending their particular naming and formatting standards.
Let me explain my standard: I try to be consistent, except when I’m not. Anything more than that runs the risk of hitting rationalist stupidity, like tblDdltbl.
So what does this mean? Well, I have a particular naming format for tables: give the table a clear, unambiguous name that describes the entity this table implements. Anything more than that is unnecessary cruft, and if I ever have to look at a chart to translate a table name, I know I’ve failed. We get 128 characters for our names, so even very long names work, and auto-complete saves your precious fingertips so you can spend more time chatting on Facebook.
Okay, so what about stored procedures? Well, name them in a way that makes sense. I like Grant’s [Object][Action] combination, but be consistent…except when it makes sense not to be consistent. Sometimes, [Object][Action][Predicate] is necessary, but that doesn’t mean you have to re-name all of those [Object][Action] procedures. And if you want to use [Action][Object] instead, that’s fine: just be consistent.
With database objects out of the way, what about formatting? I could write an MLA-length document on precise formatting of SQL code, but what’s the benefit? Is there any point in indenting here versus there, commas here versus there, or splitting out into lines here versus there? Maybe. But here’s the problem: we don’t really have any solid metrics on this, so all of this comes down to stylistic preferences. You may see your preferred formatting pattern as the pattrern, but that’s little more than an opinion based on the relatively small sample of formatting styles to which you have been exposed. Furthermore, even if you write up a long style guide, chances are you’ll either hit the shoals of stupidity (tblDdltbl) or have gaping holes that you never thought about, thereby requiring actual independent thought and the risk of non-consistent code styles.
Let’s give an example of that now. There are certain things which I believe make SQL code easier to read: columns on separate lines, primary clauses (e.g., SELECT, FROM) outdented and the only thing on the line, subqueries following consistent indentation patterns, etc. When I write a procedure or view, I tend to do that, except when I don’t: for example, trivial NOT EXISTS subqueries might end up on one line rather than broken out. But what constitutes a trivial NOT EXISTS clause? Just a SELECT and FROM? SELECT and FROM with one element in the WHERE clause? Maybe an INNER JOIN somewhere? Would splitting this out into several lines make that particular procedure significantly more difficult to read? And if not, why should I put much mental effort into following The One True System?
I get the notion of trying to have a single coding style which everybody can follow to try to make it easier to read other developers’ code, but we live in the world of auto-formatting. If you don’t like the format, it’s trivial to reformat code to your preference. Or, better yet, get over it: the interpreter doesn’t really care how you format your code, so if it makes sense to you, go for it. Just don’t pretend that what makes sense to you is scientifically superior (unless you have the studies to back this up) or even makes sense to everybody else.
