Chapter 2. Suggested Conventions

for RuBoard

Programming is like playing golf: it can be tedious and can frustrate you to your wit's end, but it's that one good shot out of a hundredthe one that zips down the fairway, around the trees, and up on to the green two feet from the cupthat keeps you coming back for more.

H. W. Kenton

I must admit a certain amount of trepidation about recommending what coding and formatting conventions you should use. Formatting and stylistic concerns are so personal and vary so much from programmer to programmer that I'm really not comfortable telling you what conventions you should use. Instead, I'll tell you what conventions I use and why.

Before I get into this, let me say that I don't think that using a particular system of coding conventions or formatting styles makes one a better programmer in and of itself. I think you should choose what works best for you. It's unlikely that following a rigid set of conventions will make you a vastly superior stored procedure developer. That said, not consistently following reasonable conventions can hamper you as a developer. Just ask anyone who's had to look at code that's formatted so strangely that it's difficult even to read, let alone figure out from a process standpoint. It's kind of hard to debug or extend code that you first have to decipher.

Also, I think the entire subject matter of stylistic conventions registers at the lower end of the spectrum in terms of importance. How you format your code isn't nearly as important as, say, what that code does and how it does it. That said, I get asked about coding conventions and source code formatting a lot, so it seemed reasonable that I should include my thoughts on the subject in this book.

for RuBoard