This month’s invitation comes from Mala who asks us about the T-SQL coding rules relevant for where we work. There’s certainly a lot of scope in this question and Mala links to a great set of posts from Robert Sheldon which cover quite a number of these points. Whilst larger businesses may well have matured standards in place across their functions I thought it would be worth touching on experiences in a smaller environment for comparison.
Readability
For me, the readability of the code is key. I’m not too fussed if some folks like to put their commas at the start of end of a line, or if they prefer their JOIN clauses over one or multiple lines. The key thing when picking up some code is being able to understand what is going on without trying to decipher exactly what has been entered.
So long as there’s basic, consistent formatting then I’ll take it. For example using new lines where appropriate – I don’t mind if there are a couple of things on one line or a new one for each part of a statement – but I’m not a fan of single-line queries, or blank lines within the query making it look like multiple.
Yes, I know we have tools like poorsql.com but I’d rather not resort to these whenever I open up someone’s code just to try and make sense of the query.
Commenting
This only just slips into second place for me. Commenting can be a critical part of the coding process, particularly when we’re revisiting older or recently modified code.
Commenting can help provide understanding to what logic has been implemented and why it’s been done that way when we’re looking at either complex or longer chains of statements. It can help guide you to the right section of code when you know what you’re looking for and let you get on with what you’re there to deal with.
Additionally if you don’t have rigorous source control processes within the team or you have work items tracked in multiple ways it can be so beneficial to have changes commented in the code to let you know who changed what and when and why. This can help isolate a recent change which is causing an issue, or give a good indication of the last time any changes were made to help rule out that section of code (if everyone is adhering).
You get bonus points if you leave the old code commented out so it’s easier to revert any changes too.
Communication
I know, a little odd when talking about coding right – but Mala gives a great example on the invitation of avoiding the NOLOCK hint and its something I’ve seen most often from folks with a BI background where they might not be getting into the workings of SQL as much as we might.
In smaller teams I think the communication is critical as the knowledge – and possibly more importantly experience – is likely not spread around as much as it can be when the team are trying to keep pace with their day to day work.
This is where the communication can be key – you can help to share the knowledge and experience with those who need it, either to help them understand the subject, the goal, the approach better – or to or it might be to help them understand what approaches are available and why one more may be appropriate than the others.
This type of communication and sharing should help to improve the quality and consistency across the team if it’s done well and everyone is full on-board with seeking and accepting any feedback or knowledge they receive.
Wrap up
I think that coding standards in larger organisations will certainly help with consistency and reduce the friction of handing off and supporting work across multiple teams. That said, I also think that in smaller teams getting some fundamental baselines in place would be much more beneficial than worrying about what case things are in for example.
I’m certainly looking forward to seeing other folks views on this topic, I’m sure there will be some interesting thoughts out there!
Andy Brownsword 