I received a great collection of blog posts in response to my T-SQL Tuesday 151 – asking people to write on T-SQL Coding Standards.
Rob Farley (t|b) is of the opinion that coding values that help with efficiency are better than rigidly enforced standards, although he as a consultant abides by his customer’s needs in this regard. ‘Coding standards are not a bad thing. But I think values are better. Valuing readable code, valuing comments that explain the reasons for coding decisions, and valuing patterns that avoid problems, can raise the quality of the coding culture’.
Tom(b) from Czech republic has a neat list of standards they abide by and try to enforce. I particularly liked what they said on specifying nullability on temp tables/table variables, and on code being idempotent – re runnable.
Kevin Chant(t|b) talks about being consistent, and the importance of short, informative comments. Both points are valid and useful.
Aaron Bertrand(t|b) has an amazing post on ‘controversial standard’ CAST Vs Convert – I really enjoyed reading this one. I always use CONVERT personally, but was not aware of the gotchas with CAST that he points out – such as with yyyy-mm-dd and British date, and of CAST being unsupported in other platforms. CONVERT for the win, and am glad I stuck with it. Aaron’s posts are always very informative, and packed with some snarky humor as well. Don’t miss reading this one!
Glenn Berry(t|b) has a nice post where he talks of some basic coding standards, defends his use of NOLOCK and OPTION RECOMPILE on his DMV queries (I believe this is totally fine and use his queries extensively). In the end , he too is of the same opinion as Rob Farley – that ‘it is much more important to have functional, readable code that performs well and is easier to maintain.’.
Deborah Melkin(t|b) has a post that lists the coding standards she thinks are important. She raises an important point – do you fail a PR if a standard is not met if it is not that critical, or just flag it as something to be fixed later? She also discusses the burden of being the ‘one person’ on the team who has to enforce standards and how hard that can sometimes be.
My good friend Steve Jones(t|b) lists a few standards he thinks are important but emphasizes that it is important there is a standard to begin with. He also has a gentle rebuke for me for hosting this blog party 4 times and wants more new folks to start hosting T-SQL Tuesdays going forward. If you are reading this and are interested in hosting, please contact him on twitter.
Deepthi Goguri(t|b) has an excellent blog post on T-SQL practices she wished she knew earlier..it is packed with various tools and tips any T-SQL programmer can use. I did not know of PoorSQL as a formatting tool, and I also appreciated the tip on updating statistics after importing a large number of rows. Well done, Deepthi!
Ken Fisher(t|b) talks of organizational politics with standards – and the importance of having one set of standards everyone in the organization agrees to. I can totally see how this can be a problem in a large organization.
Gerard Jaryczewski(t|b) is writing his first T-SQL Tuesday post – welcome Gerard!! He talks of the importance of simplicity and consistency as T-SQL Standards, naming conventions and adhering to the naming convention of the domain the language uses.
Hugo Kornelis(t|b), an amazing friend I look to for T-SQL related knowledge and guidance talks about having one standard and sticking to it even if you disagree. He also has an interesting take on prefixing view names, something I freely admit I’ve done and enforced as a standard many times..Hugo believes tables and views have to be interchangeable, so you don’t need to be named differently and there are other ways to find out if something is a view..my take personally has been that view is considered code while a table isn’t..so knowing what is code helps in including it for various purposes of analysis. Regardless I respect Hugo’s stance and will consider it going forward for my standards too.
My good friend Tracy Boggiano(t|b) has some great tips on readability here. She also suggests putting performance ahead of any formatting related standards.
To summarize, the lessons I learned are as below –
1 It is important to have standards
2 Pick one set of standards and stick to them.
3 Respect standards at the client (if you are a consultant) or existing standards wherever you go.
4 Performance and code that functions right is more important compared to how it looks, although readability matters too.
5 Standards include stuff that you shouldn’t use, like CAST instead of CONVERT.
6 Many other standards are buried in the posts above.
7 Sign up with Steve to host a T-SQL Tuesday, if you haven’t already!!
That is it!! Thank you to everyone who participated and sharing your nuggets of wisdom.
Curious..about data 