This month the T-SQL Tuesday blog party is hosted by my good friend, Mala. This is her fourth time hosting and she has a good topic this time. While I love her hosting, and a few others, I would like to see more people participate and take a month on their technology of choice.
You can submit to host by contacting me on Twitter and reading the host page.
Coding Standards
I am a big fan of standards, both for coding and naming, when building software. I feel that having some standards help share information among staff. Since staff might come and go on a project, the less friction that we have, the better off we are.
With that being said, the main standard for me is that the team has a standard. Preferably the organization has a standard, but we want to ensure that everyone follows a similar style of coding. This includes naming and style.
For example, if we want plural names for all entities, let’s stick to that. I think singular makes more sense, and despite my habit of years of plural, I have been working to change. If my team wanted to go one way or the other, I’d just work with them.
The same thing goes for commas. I like commas before a column list, but if the team prefers after, then that’s OK. I can adapt. Especially with a tool like SQL Prompt that let’s me easily reformat to another style.
The other advantage of coding standards, apart from transferring information, is that we can use templates and snippets of code as a way to speed up coding. We can even write or use code generators to ensure that we build the code that everyone understands.
A Few Specifics
For me, these are things I’d set up if there were no standards. I’d be welcome to debate on them and be willing to change. These are for SQL. For other languages, there would be similar choices based on the language.
- commas before column list columns
- start column list on a new line
- FROM, WHERE, ORDER, GROUP, HAVING all indented 1 space or tab from left
- I prefer spaces, but only lightly.
- align all clauses in WHERE on separate lines
- entities use singular names
- primary keys are named <tablename>PK
- if surrogate keys, use <tablename>ID as the column header
- FK constraints use FK_<source>_<destination>_<column1>_<column2>
- ALL indexes named as CDX_<table>_<column> for clustered or NDX_<table>_<column> for non clustered. CCX or NCX for columnstore.
- FK column in the child table uses the same name as the PK column in the parent.
There are more, but this is a quick list. The important thing is to have standards.