blogs.conchango.com

welcome to the conchango blogging site
Welcome to blogs.conchango.com Sign in | Join | Help
in Search

SSIS Junkie

Source Analysis for T-SQL perchance?

My learned colleague Howard van Rooijen recently blogged about the new release of Microsoft Source Analysis for C#  (aka StyleCop) and his enthusiasm for the tool was near-tangible.

This tool analyses your source code and suggests changes that may be in line with best practice coding skills and the ultimate aim is for a consistent look-and-feel to C# code. As StyleCop author Jason Allor says:

“Source Analysis focuses on layout, readability and documentation”

When I read about it I started to wonder about what a similar tool for T-SQL might do. When I write T-SQL code I generally follow these guidelines for layout, readability and documentation:

  • multi-line SQL statements - new line per predicate, 1 column per line
  • tab indentation
  • commas at the beginning of a line rather than the end
  • capitalised keywords
  • two-part names
  • everything aliased (with full use of the AS keyword)
  • camel-cased object names
  • reserved words that are used as object names marked with square brackets
  • line spaces between separate SQL statements
  • comments where appropriate

Hence, if you were to give me the following snippet of T-SQL code:

declare @objectid int
set @objectid = (select object_id

from  sys.tables
where name = 'Address'
) 
select      name, case when system_type_id = 56 then 'int' when system_type_id = 231 then 'nvarchar' else 'sql_variant' end datatype, precision, scale
from  sys.columns where object_id = @objectid

 

I would probably give it back to you looking something like this:

 

DECLARE     @ObjectId   INT


SET         @ObjectId = (     SELECT   t.object_id
                              FROM     sys.tables t
                              WHERE    t.name = 'Address'
                              )

//use previous discovered ID in the next statement’s WHERE predicate
SELECT      c.name
,           CASE      WHEN c.system_type_id = 56 THEN 'int'
                      WHEN c.system_type_id = 231 THEN 'nvarchar'
                      ELSE 'sql_variant'
            END AS DataType
,           c.[precision]
,           c.scale
FROM        sys.columns c
WHERE       c.object_id = @ObjectId

 

When talking about StyleCop Jason stated:

As you might expect, many wars were fought over the nature of these rules, and much blood was shed

I imagine that there would be much more blood shed over some T-SQL rules but at least it would be fun to try and define some. So, what code formatting conventions would you like to see in a Source Analysis for T-SQL tool? Are you as particular as I am?

-Jamie

Published 02 June 2008 23:33 by jamie.thomson

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Alun Davues said:

I assume if you ask 50 different users you will get 100 different styles

I have a different style today than I had a year ago.

However I totally agree, we MUST try to standardise.

Are there no 'approved' standards already in use we could start from (Your list above does look good, I will start putting commas at the beginning of a line rather than the end from now on)

June 3, 2008 17:45
 

Tod McKenna said:

I try to stick to the same style, a style I learned from a Foxro Advisor article about 10 years ago. Don't ask me the specifics, but it stressed using CamelCase for variables and objects and UPPERCASE for keywords. Spaces are better than TABS -- especially if you want to post code to an article or into technical documentation. I also like spaces because I use 2 spaces instead of 4 in certain situations.

For the example you gave, my code might look like the following:

DECLARE @ObjectId INT

SET @ObjectId =

   (

   SELECT t.object_id

     FROM  sys.tables t

     WHERE t.[name] = 'Account'

   )  

SELECT    c.[name] AS [Name]

       , CASE

           WHEN c.system_type_id = 56 THEN 'int'

           WHEN c.system_type_id = 231 THEN 'nvarchar'

           ELSE 'sql_variant'

         END AS DataType

       , c.[precision] AS [Precision]

       , c.scale AS Scale

 FROM  sys.columns c

 WHERE c.object_id = @ObjectId

I like my lines to span the fewest number of columns as possible (I don't like to scroll right to read code, I'd rather read more lines going down the page).

But I admit that I'm not always consistent and a lot depends on what the TSQL is used for. If it is just for me or my direct team for troubleshooting or ad hoc, then I will be much looser. If it is code that is part of the 'front-room', I'd be much more careful about following conventions.

Regardless, it would be nice to have some standard to work towards.

June 4, 2008 12:07
 

Bill said:

Yes, I'm plenty particular about my TSQL.  In most cases, I think I'd rather have the "wrong" style applied consistently across a codebase vs 20+ unique and incoherent^W inconsistent styles.

My style is more in line with Tod's but the general case is I'd rather have it long vs wide.  I've dealt with Java and python long enough that I've given up on tabs and always use spaces (4).  Comments are never used frequently enough.  I can find far too many procs that only have a comment of -- SET NOCOUNT ON added to prevent extra result sets from interfering with SELECT statements

and then it runs along doing convoluted and not always accurate busines logic.

I'm totally on board with two part names, aliases and your comma preference.  I much prefer column aliases with T1.col1 AS MyCoolAlias vs MyCoolAlias = T1.col1 but either is preferred to unnamed columns in the case of SUM(t1.col1)  Even in single table queries, I prefer to see my columns qualified.

I am less particular about variable names although I do prefer a camel case or pascal case versus one with underscores.  

I need to scoot to a meeting but a good topic and excellent fodder for a holy war.

DECLARE

   @objectId int

SET

   @objectId =

   (

       SELECT

           ST.object_id

       FROM  

           SYS.TABLES AS ST

       WHERE

           ST.name = 'Address'

   )  

SELECT

   SC.name

,   CASE

       WHEN SC.system_type_id = 56

           THEN 'int'

       WHEN SC.system_type_id = 231

           THEN 'nvarchar'

       ELSE 'sql_variant'

   END AS datatype

,   SC.precision

,   SC.scale

FROM  

   SYS.COLUMNS AS SC

WHERE

   SC.object_id = @objectId

June 4, 2008 16:38
 

ames said:

I don't like multiple spaces between related lines.  I prefer to see all or most of the code at a glance.  However I do put the first variable or field on a separate line from the keyword like so:

DECLARE    

           @ObjectId   INT

SET @ObjectId = (   SELECT  

                                       t.object_id

                             FROM    

                                       sys.tables t

                             WHERE    

                                       t.name = 'Address' )

//use previous discovered ID in the next statement’s WHERE predicate

SELECT      

           c.name

,           CASE      WHEN c.system_type_id = 56 THEN 'int'

                     WHEN c.system_type_id = 231 THEN 'nvarchar'

                     ELSE 'sql_variant'

           END AS DataType

,           c.[precision]

,           c.scale

FROM        

           sys.columns c

WHERE      

           c.object_id = @ObjectId

June 4, 2008 19:23
 

Jon Ochmanek said:

I haven't played around with it much yet, but I believe RedGate's SQL Refactor provides the ability to format the SQL to a customizable format.  Again, I'm sure there's a catch, and I'll let you know once I get the trial version installed, but looks like a good idea.

As for my opinion, spaces over tabs (drilled into my head thanks to Python), three part names, and single space over double spacing.  I also am partial to the (nonstandard) practice of commas at the end of line instead of the beginning, but I'll catch some heat from that one.

June 9, 2008 18:10
 

Steven Lee said:

I recommend this free online sql formatter,  use it every day.

http://www.wangz.net/gsqlparser/sqlpp/sqlformat.htm

June 17, 2008 03:14
 

HJ said:

how about using Red-Gate's SQL Refactor. It does more than just beautify your code...

June 17, 2008 22:12
 

Jeff Jordan said:

Another great free formatter (that has a downloadable java version as well as the online version) is SQLinForm http://www.sqlinform.com/

That said, it would be much better if the formatting was integrated in to SQL Server Management Studio the same way code formatting has been for quite some time in Visual Studio.  That's a clear advantage for Redgate that may make it worth buying.

June 24, 2008 14:42
 

LDN said:

I agree with most of your suggested guidelines for laying out TSQL.  Disagree with tabs and capitalization of keywords.  I prefer indents consisting of four spaces; the formatting is never lost when switching among editors.  I believe the capitalization of keywords started with Joe Celko -- when editors were in black and white.  Editors now color keywords blue.   Lower case doesn't SHOUT off the page and is more pleasing to my eye.

July 9, 2008 20:03

Leave a Comment

(required) 
(optional)
(required) 
Submit

This Blog

Syndication

News

Powered by Community Server (Personal Edition), by Telligent Systems