This first contribution to T-SQL Tuesday will be about my rules of thumb while coding T-SQL. The focus will not be on design aspects but merely on how you can write code so your co-workers and clients are able to understand what the code should be doing. Readability is a keyword here. This includes code formatting and very important: the use of comments (or remarks so you like).

How many times have you been asked to debug or alter a stored procedure which didn't come with a single line of documentation or comments? Too often probably. Therefor try to think of all the people looking at your code. Maybe even try to think of yourself reading your own code. Will you understand what a stored procedure is supposed to do? Will you know why you made certain design decisions in your query or how this complicated query is structured?

Adding comments to your code is simple. T-SQL provides two elements you can use for this purpose:

-- text_of_comment

/* text_of_comment*/

So please take a moment in your development cycle and add (meaningful) comments.

Now take a look at the formatting of your code. How does it look? Does it comply with company standards (if there are any)? Were you consistent with the use of UPPER en lower case keywords? Did you properly indent your statements? If it looks fuzzy on screen it is fuzzy! Because everyone on your team has a different idea of what code is neatly formatted and what not you should take the time to sit down and write down some conventions on how your code should be formatted.