Will Terminators Be Required?

Question

Will Terminators Be Required?

Steve Jones - SSC Editor

SSC Guru

Points: 734418
More actions
August 5, 2018 at 9:08 pm

#356761

Comments posted to this topic are about the item Will Terminators Be Required?

Viewing 15 posts - 1 through 15 (of 34 total)

You must be logged in to reply to this topic. Login to reply

John Rees Mr or Mrs. 500 Points: 571 More actions · Answer 1

I think it's important that languages are allowed to evolve safely, otherwise the mistakes of our ancestors will forever burden us. Look no further than \r\n or should I say \n, or even \r. Seemingly insignificant decisions can have far reaching consequences, and they slow us all down. Maybe each developer loses only 5 minutes a week thinking about line terminators, or semicolons, but that adds up to a lot for all of us, every year, forever!

I think one small hope for language change is the slow, but relentless, adoption of devops. These techniques push the idea that change can be managed more easily than before. If we can make the test cycle less painful, then people will be able to cope with new releases without panic.

Also, there has to be adequate warning, and easy ways to find problems before they occur.

For instance, in SQL 2020 they could announce:

New database option: TerminatorsAreMandatory (True/False)
In SQL 2020 TerminatorsAreMandatory is False by default.
In SQL 2022 TerminatorsAreMandatory will be True by default.
If TerminatorsAreMandatory is False, then every execution of SQL that does not use terminators will be logged in SomeFile.log

The last one about logging problems without causing failure is vital.. There has to be an obvious way to track down offenders ahead of time at leisure.

So I don't believe its hopeless. If the change has a benefit, it can be done, but there has to be an appetite for it, or it's doomed. Each individual may think it's a pain while its happening, but it eventually helps everyone (just a little bit 🙂 ).

P.S. I don't feel strongly about the SQL terminators issue specifically, but how to cope with software change in general is interesting.

David.Poole SSC Guru Points: 75896 More actions · Answer 2

I work with a number of databases and also database tools. Some expect a semi-colon terminator, others don't.

One of the reasons that the NOSQL crowd started adopting a SQL like language or that numerous products offer SQL over technology 'x' is because they've discovered that having to learn a new query language for every data product is really hard. Each product having its own language creates barriers to adoption.

SQL isn't implemented the same across all RDBMS products let alone for the NOSQL DBs.

I use the semi-colon batch terminator for consistency purposes. It reduces my context switching. I can focus on what I am supposed to be delivering rather than the mechanics of that delivery.

LinkedIn Profile

scoan Old Hand Points: 347 More actions · Answer 3

scoan

Old Hand

Points: 347

August 6, 2018 at 1:53 am

#2000372

F%$#)ing semicolons

sean redmond SSCertifiable Points: 5816 More actions · Answer 4

I agree with John Rees' suggestion but I'm more fascist about it.

I'd rather the warning be, from the first release in 10 years' time (a specific year can be given), semi-colons will be mandatory or that old-feature x will be deprecated, rather than giving a vague threat (it will be mandatory in future),
This way legacy code can be brought up-to-date and deprecated features can be handled.
Lines need to be drawn in the sand.

I note that Microsoft don't just say, support will be withdrawn in the future, they give a specific roadmap as to until when what levels of support will be available. Something like this for upcoming and deprecated features would be welcomed.

Alex Gay SSCrazy Points: 2211 More actions · Answer 5

This help file wording for the command terminator has been part of the Transact-SQL documentation for as long as I can remember, going back to SQL Server 7.0. Colleagues say they can always tell when I have written code because of the use of semi-colons to terminate statements. I do this because when (if) they do become mandatory I want my code to keep working, and not have to go back and update every piece of running code that I have ever written. This is because I am lazy, I don't want to make additional work for myself in the future.
Microsoft, on the other hand, seem to feel the opposite, and the staff in question probably won't be on the SQL Server development team when the omission of a semi-colon becomes a problem. Looking through any of the internal system procedures I am struck by the lack of consistent formatting, and the lack of row terminators of any kind.

dsor SSChasing Mays Points: 656 More actions · Answer 6

I expect we'll get a tool that puts the semicolons in place to upgrade old sql automatically. The remaining issue then would be any dynamic queries left, which in a reasonable database should be few enough to locate and fix in an afternoon.

Roland Alexander STL SSCrazy Points: 2915 More actions · Answer 7

I'm a proponent of using the terminator, and enforce it via a clear coding standard and code walkthroughs and reviews. For legacy code, we use SQL Prompt's Format feature, which will go through and add a semicolon to every statement. Consistency to me is the key: either do it, or don't, and since all the really cool new language features from 2008 on require it, well, it's pretty much a no-brainer.

Roland Alexander
The Monday Morning DBA
There are two means of refuge from the miseries of life: music and cats. ~ Albert Schweitzer

Aaron N. Cutshall SSCrazy Eights Points: 8992 More actions · Answer 8

I agree with John Rees in that there should be an option to turn it on so I can ensure that my developers use it consistently like I do. I also agree with Alex Gay in that the primary reason it hasn't been enforced at this point isn't for OUR benefit, but more for Microsoft's because they would have to update all of the system stored procedures. If a tool is created, as reasonably suggested by dsor, to update our code with terminators, then why hasn't that been done already?

Seeing statements preceded by a semi-colon really bugs the crap out of me because it's NOT a statement prefix! Instead of patching around a problem, let's just fix the issue and move on! Are you listening Microsoft??

LinkedIn: http://www.linkedin.com/in/sqlrv
Twitter: http://www.twitter.com/sqlrv
Website: http://sqlrv.com

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 9

scoan - Monday, August 6, 2018 1:53 AM
F%$#)ing semicolons

Heh... even though I use them all the time and very consistently so I don't have so much change when the shoe finally drops, I just had to give this one a +one... the way I used to judge the people that wrote a compiler or interpreter was whether or not if required a "thought" terminator. That and whether or not it required braces. 😉

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Dan Guzman SSCommitted Points: 1506 More actions · Answer 10

Although not using semi-colon statement terminators has been deprecated for a decade, using statement terminators is still the exception rather than the rule, even in new development. I'm rather particular about using semi-colon terminators myself event though I don't expect terminators to be a T-SQL requirement in my lifetime.

A pet peeve of mine is seeing semi-colons used improperly, preceding a statement instead of terminating one, just to avoid a compile error. I personally don't think it's all that difficult to place the terminator in the proper place, terminating the previous statement. I wish the T-SQL parser was more strict in this regard and adhered to documented syntax.

Not using terminators can introduce some nasty and unexpected behavior: https://www.dbdelta.com/always-use-semicolon-statement-terminators/

--
Dan

Ralph Hightower SSCrazy Points: 2843 More actions · Answer 11

This sounds like it may be another Y2K type scope of project.

rustprooflabs SSC-Addicted Points: 404 More actions · Answer 12

I use semicolons everywhere because I spend as much time in PostgreSQL as I do MS SQL. In PostgreSQL the semicolon to terminate statements is required everywhere there is more than one statement. I found it frustrating when I first started with PgSQL but once you train your fingers, you don't even notice...

roger.plowman SSChampion Points: 10265 More actions · Answer 13

Shades of Pascal...bleh

I actually have started using semi-colons to terminate lines, but I have to say T/SQL syntax is a nightmare mish mash of 1960s era design that somehow escaped the Grim Reaper...much to everyone's sorrow.

Of course everything comes back to two basic syntax design mistakes. At least design mistakes in my opinion.

First and foremost is the lack of explicit line termination by ending a line (ala like just about every other damn language on the planet). Second is the escaping of characters by repeating them (single quote, I'm looking at you).

Those two issues are 99% of what allow code injection attacks.

Of course fixing these mistakes is now literally impossible, nobody is going to rewrite the trillions (probably) of lines of code that currently exist. So we live with the hopelessly broken syntax.

Sigh. :crying:

Jeff Moden SSC Guru Points: 1003853 More actions · Answer 14

Dan Guzman-481633 - Monday, August 6, 2018 6:21 AM
Although not using semi-colon statement terminators has been deprecated for a decade, using statement terminators is still the exception rather than the rule, even in new development. I'm rather particular about using semi-colon terminators myself event though I don't expect terminators to be a T-SQL requirement in my lifetime.

Heh... for proof of that, just look at the MS provided system stored procedures. Man, they've got a whole lot of work to do before the make semi-colons a requirement.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)