While it might be obvious that it's important to format your T-SQL code for readability, it might be less obvious that there's no agreed standard for how to format that code.
Everybody has their own style. The main thing. People will tell you all the time is just to be consistent. But then they'll tell you they don't like the format you've used.
Take a reasonable style and then to just keep applying it.
Here's an example of the core elements of a pretty standard style:
- T-SQL keywords capitalized i.e. SELECT
- Database object names PascalCased i.e. ProductGroups
- Local variables start with @ and PascalCased i.e. @Size
- Constants capitalized with underscores separating words i.e. MAXIMUM_INTEREST_RATE
- Blocks indented i.e.
|
1 2 3 |
BEGIN SELECT END; |
One common variation is to use what's called snake_case instead of PascalCase. The words are all lower-case with underscores between them. I've seen arguments that snake_case is actually easier to read than PascalCase.
For indentation, I tend to work with four spaces as the Indent. Some People use tabs for this . There's a strong argument between People who love spaces and People who love tabs. It's not really something that I feel religious conviction about but I've heard it argued that having tabs instead of spaces has two benefits:
- People can adjust the tab size to suit themselves
- Tabs work better for people with visual disabilities, particularly with screen-reading tools.
Now there are many, many other standard rules, you might want to apply encoding, but these will get you started.
Learning T-SQL
It's worth your while becoming proficient in SQL. If you'd like to learn a lot about T-SQL in a hurry, our Writing T-SQL Queries for SQL Server course is online, on-demand, and low cost.
Don't alias tables unless you have to (e.g. when you need to reference the same table twice in a statement).
If you absolutely HAVE to alias tables, don't use single letter alias names.
Personally, I can't bear leading commas:
SELECT
Id
,GivenName
,FamilyName
FROM
Users
Hi Edward, can't say I agree.
I was in that same camp on the not aliasing unless needed but over the years I've changed. So many queries that start single table end up multiple table over time, and also, Intellisense works way better in that way.
As for single letter aliases, I don't see an issue with c for customers and p for products when they are the tables in the query. I only go to multiples when there's a clash. However, I'm not talking about a, b, c, d as table aliases (unrelated letters). That's horrid.
I prefer commas trailing but I've worked at sites that do it the other way. I can see arguments for both and I don't think there's a knockout case for either way.
I usually prefer the alias to have same number of characters as the number of words in table name e.g. p for Products, pt for ProductTypes, etc.
Totally agree. If I have ProductModels, I'll use pm as an alias. I take the first letter of each word in the name.
What I also do is that if I have two names that start with the same letter, then I do move to longer aliases, usually three. So if I have Customers and Channels, I'd then use cus and cha.