Is there a good reason to use upper case for SQL keywords? [closed]

The default seems to be upper case, but is there really any reason to use upper case for keywords? I started using upper case because I was just trying to match what SQL Server gives me whenever I tried to create something, like a new stored procedure. But then, I felt terrible for my baby (5th) finger, that always needs to hold down the Shift button, so I stopped using upper case. Any reason why I should go back to upper case?

Edit: Thanks for the answers guys. I wasn't programming yet back in the days when COBOL was king, so I wasn't aware of this. I'll stick with lower case from now on.

Solution 1:

PERSONALLY, I DON'T LIKE MY SQL YELLING AT ME. IT REMINDS ME OF BASIC OR COBOL.

So I prefer my T-SQL lowercase with database object names MixedCase.

It is much easier to read, and literals and comments stand out.

Solution 2:

It's just a matter of style, probably originating in the days when editors didn't do code colouring.

I used to prefer all upper case, but I'm now leaning towards all lower.

Solution 3:

SQL IS OLD. UPPER CASE IS SHOUTING. IT LOOKS STRANGE AND PERHAPS UGLY.

While arguably true, none of those address the reasons special to the SQL language why upper-case keywords are a good convention.

Unlike many newer languages, SQL has a large number of keywords and relies on the reader's ability to distinguish keywords versus identifiers in order to mentally parse the syntax.

The direct answer to your question, then, is more an answer to “why does the reader of SQL code benefit so much from uppercase keywords, when that's not as true for most modern languages?”:

To rely on keeping the keywords in one's head is reasonable for many modern languages, but unreasonable for SQL; it has too many keywords, and too many variants.
To rely on punctuation cues is reasonable for most modern languages, but unreasonable for SQL; it has too few, instead depending on the precise order of keywords to indicate syntax.
To rely on automatic highlighters for distinguishing keywords is reasonable for modern languages in usual cases, but ignores the reality of what highlighters can achieve for SQL. Most don't cover all keywords of all variants of SQL, and regardless, SQL is frequently and routinely read in contexts where a highlighter won't help.

These are some of the reasons, specific to SQL, that the reader of SQL code is best served by standardising on upper case for keywords, and only using not-upper (i.e. lower, or mixed) case for identifiers.

Highlighting can sometimes help. But only if the highlighter knows you've got SQL; and we very often have SQL in a context where the editor/formatter can't reasonably know it's dealing with SQL. Examples include in-line queries, programmer documentation, and text strings within the code of another language. The same is not true anywhere near as often for languages like Python or C++; yes, their code does sometimes appear in those places, but it's not routinely done the way it is with SQL code.

Also, the reader will commonly be using a highlighter that only knows a subset of the keywords your specific SQL implementation uses. Many of the less-common keywords won't be highlighted except by one that knows your SQL variant intimately. So the reader, even if they're using a highlighter, still needs some more direct way of distinguishing keywords in any moderately-complex SQL statement.

Thus the reader will frequently – and the writer can't know ahead of time when that will be – need assistance from the content of the SQL statement itself, to know what's intended by the writer as a keyword and what's intended as an identifier. So the SQL content itself needs to distinguish keywords for the reader, and using uppercase keywords is the conventional and useful way to do that.

Solution 4:

THERE WAS A TIME WHEN MOST PEOPLE DID NOT HAVE THE POSSIBILITY OF ENCODING ANYTHING BEYOND UPPER CASE LETTERS BECAUSE THE RELEVANT ENCODING (ASCII) WAS NOT YET INVENTED. ONLY SIX BITS WERE AVAILABLE. WHILE SQL IS MORE RECENT, LOWER CASE LETTERS WERE NOT COMMON PRACTICE IN PROGRAMMING YET.

NOTE THAT SOME PEOPLE CLAIM THAT THE DATABASE WILL GET A SENSE OF URGENCY AND RUN YOUR QUERIES FASTER.

Solution 5:

Gordon Bell's examples are not exactly correct; generally, only the keywords are highlighted, not the entire query. His second example would look like:

SELECT name, id, xtype, uid, info, status, 
base_schema_ver, replinfo, parent_obj, crdate, 
ftcatid, schema_ver, stats_schema_ver, type, 
userstat, sysstat, indexdel, refdate, version, 
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1

I find this far easier to read, since the keywords stand out more. Even with syntax highlighting, I find the uncapitalized example much harder to read.

At my company, we go a little bit farther with our SQL formatting.

SELECT      name, id, xtype, uid, info, status, 
            base_schema_ver, replinfo, parent_obj, crdate, 
            ftcatid, schema_ver, stats_schema_ver, type, 
            userstat, sysstat, indexdel, refdate, version, 
            deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
    sysobjects.col1=systhingies.col2
WHERE category = 0
    AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1