Missing Semicolons: My Earliest Warning Sign of a SQL Server Codebase
One of the earliest signs that I’m about to have a rough time with a SQL Server codebase is when I notice that semicolons aren’t used as statement terminators. And I’m not talking about the occasional missing semicolon; I am talking about not using semicolons as a best practice. I’m living through that experience right now.
To be clear, not using semicolons isn’t inherently terrible. SQL Server still allows it, and plenty of successful applications have been built without them. At the end of the day, it’s largely a stylistic choice.
What I’ve found, though, is that missing semicolons are often an early indicator that I’m about to encounter a whole collection of other “best practices” unique to that codebase. The semicolons themselves aren’t the problem; they’re simply the canary in the coal mine that tells me I’m about to learn a very particular way of writing SQL.
Yes, SQL Server still allows you to omit semicolons. They’re optional for now. Microsoft has been saying for years that omitting semicolons is a deprecated feature and that future versions of SQL Server will require them. Personally, I wish there were a SET option that forced semicolons to be mandatory so teams could adopt the standard today instead of waiting for a breaking change years down the road.
When I hear someone argue that not using semicolons is a “best practice,” I immediately know what I’m walking into. It’s usually a codebase that has been shaped by a single developer who learned SQL in a vacuum decades ago and has been with the company ever since. The formatting isn’t based on modern conventions or maintainability—it’s based on what one person has become accustomed to reading, and all SQL code reviews go through this single developer.
For me, reading SQL without semicolons feels like reading a book without punctuation. I can still understand it, but it takes more effort than it should. The missing semicolons are just the indicator of stranger things to come. I know I’m going to find all sorts of interesting ways the developer deviated from the norm and went against common standards.
SQL is sometimes jokingly said to stand for “Scarcely Qualifies as a Language,” but that doesn’t mean it should be treated as one. One of SQL’s strengths is that it’s a descriptive, almost prose-like language. The goal should be to write code that is easy for the next developer to read and understand—not to cram everything into as few lines or characters as possible.
On a side note, I used to have a little fun with interns by telling them they should write all of their SQL on a single, really long line because it would execute faster. It was always entertaining to see whether they’d question it or spend a few minutes trying to figure out why that would or wouldn’t make sense. Unfortunately, ChatGPT and other LLMs have taken some of the fun out of those harmless pranks. Instead of wondering whether I’m serious, they just ask an AI and come back with the correct answer.
Anyway, back to missing semicolons… and this isn’t just about aesthetics.
There are practical reasons to terminate every statement. For example, if you’ve ever had to pull SQL text out of execution plans or DMVs, you know that SQL Server stores only a limited amount of text. Queries are frequently truncated. When statements are properly terminated with semicolons, it’s much easier to determine whether you’ve captured the complete statement or whether the text has been cut off. That small character can save you time during troubleshooting.
The missing semicolons are usually just the first clue. Once I notice them, I can almost predict what else I’m going to find. It’s like filling out a bingo card.
I originally planned to include that bingo card in this post; a collection of all the little code smells and bad habits that tend to show up together. But the list kept growing, and before long the post was turning into a novel. I’ll save those topics for future posts and keep this one short and sweet.
Thank you for reading!
I don’t often blog, but you can find all sorts of advanced SQL puzzles and my SQL writings on my GitHub located below. Feel free to peruse around.
AdvancedSQLPuzzles/Advanced SQL Puzzles at main · smpetersgithub/AdvancedSQLPuzzles
I’m one of those developers that does not like semicolons in SQL.
In your post you gave 1 extremely small yet correct example where a semicolon would indeed help.
To me, semicolons do not make SQL more readable, more the opposite.
Having said that, you won’t find many ‘smells’ in my SQL code.