Common table expressions were a fantastic introduction to the T-SQL language; both as a way to isolate derived table logic and facilitate previously complex problems like hierarchy/recursion. I wrote about them a few years ago in #BackToBasics: Common Table Expressions (CTEs).

All the examples in that post start like this:

;WITH cte AS (...

It's odd to see a query that starts with a statement terminator, but let me explain.

Since CTEs use an already overloaded keyword (WITH), the parser has a very specific requirement:

But many are not in the habit of properly terminating all statements (even though it's been required by the ANSI standard since SQL-92 and not doing so has been deprecated for over a decade).

Inevitably, someone will post a question with code like this:

DECLARE @foo INT
Declare @bar VARCHAR(8)
set @foo = 5
Set @bar = 'catsup'
 
Select /* <some query where a CTE would make sense> */ ...

And I want to be able to post this, encouraging better habits on multiple fronts:

DECLARE @foo int        = 5,
        @bar varchar(8) = 'catsup';
 
WITH cte AS (SELECT...

But I can't. Because almost 100% of the time, they will copy just the CTE portion and leave their existing (and admittedly not broken on its own) part of the code alone. Which then produces this verbose error message:

And since the line points directly at the code they copied from me, I start fielding complaints that my solution sucks, that it broke their existing procedure, that it killed their overnight scheduled jobs and got them paged while they were dreaming about Kenny Rogers, or what have you.

That got old. FAST.

I thought to myself, "Self, for my own sanity, how can I prevent these people from shooting themselves in the foot with my cough broken code?" Knowing that I couldn't meddle with their existing codebase, or control what they do before they jam my solution into the middle of it, I remembered that two statements can be separated by one, zero (sometimes), or a hundred statement terminators. This is terrible but valid code:

;;;; ;; ;;;;; ;;;; ;;; ;;
;;; DECLARE @i int; ;; ;;;;;
;;;;;;; ;;;;;;;;; ;;;;;
;;; ;;;;;;;;; SET  @i  =  -4; ;;;; ;;;;;
;;;;; ;;;;;;;;;;;;;; ;;;;;;
;;;;; /* I'm a comment */ ;;;;;;;
;;;;;; ;;;;;;;;;;;;;; ;;;;;;
;;;;SELECT name FROM sys.procedures;;;;; ;;;;;
;; ;;;;;;;;;;; ;;;;;;;;;

So, I thought, why not just add an additional defensive statement terminator before the CTE? Whether the previous statement already has a terminator, it can't possibly hurt anything, except subjective style points and feelings. (An exception is when a CTE is used in a view or inline table-valued function, where there isn't even a preceding statement eligible for a terminator.)

The pattern above became:

DECLARE @foo int        = 5,
        @bar varchar(8) = 'catsup';
 
;WITH cte AS (SELECT...

Like magic, the complaints stopped. (Well, to be replaced by different ones. Read on.)

Sure, it raises eyebrows, and there are industry purists that I respect who won't ever pervert their code with this atrocity. From time to time, it causes outbursts from people making fun of this so-called "begininator," or calling me defensive when I explain, or asking me if it wouldn't be better to just assume and expect that everyone terminates all their statements properly. Which makes me laugh, but brings me full circle.

Until statement terminators are mandatory (which would have also been a good April Fools' Joke), or there is a new synonym like WITH_CTE, this is what you'll continue to see from me when I'm posting CTEs for others to use or learn from.

Sorry (not sorry)

I've even started formatting answers like this to help pre-empt some of that noise:

;;; /* for safety */ ;;; WITH cte AS (...

Maybe I'll start adding a link to this post in my leading comment, too.

Note that I'm not suggesting you overhaul your own private codebase, or add leading semi-colons to code review checks in your organization. I'm certainly not adding leading statement terminators to every CTE in the codebase at Stack Overflow, and have no plans to suggest it in our internal documentation as I write up other guidelines. I'm only suggesting that, when posting sample code in blog posts and forum answers, that it's a safe, defensive, non-harmful approach for consumption by less experienced users (or holdouts on statement terminators in general).

And no, I really don't expect Microsoft to ever follow through on their long-standing deprecation notice, or add a synonym to give us a more parser-friendly option.