Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
3 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
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.
0 comment threads
Though probably not the original reason, I would say it's still useful as it brings some kind of distinction between keywords and variables/columns, since SQL consists mostly of words with less punctuation than other programming languages. Consider:
SELECT name FROM animal LIMIT 10
which contains only spaces as non-alphanumeric characters.
vs
animal.filter(limit=10)
containing a dot, a pair of parentheses and an equals sign as non alphanumeric characters.
Of course, there's syntax highlighting to show the distinction, but I think caps still add something.
0 comment threads
Since the tradition doesn't have any enforcement anywhere, we can't necessarily pinpoint a single reason, but it probably has a lot to do with the available technology of the early 1970s when Chamberlain and Boyce put together the original SEQUEL. Specifically, punch cards and teletype machines generally didn't support multiple cases of character, even when the computer itself might.
However, COBOL notably follows many of the same conventions, and SQL takes a lot of cues from COBOL. Speaking of which, COBOL's metalanguage (used to describe the language) might also have some influence, where it uses all-uppercase to identify reserved words.
I should also mention that FORTRAN has a similar tradition, but while it has a similar age to COBOL, we haven't generally heard about programmers developing with FORTRAN and SQL.
0 comment threads
0 comment threads