5 ms·

Tangentially related. I'm of the opinion that SQL shouldn't be uppercased. I don't want to hit shift or caps lock and I find lowercase easier to read. Are ther

Tangentially related. I'm of the opinion that SQL shouldn't be uppercased. I don't want to hit shift or caps lock and I find lowercase easier to read. Are there others out there like me? I assume I'm in the minority, but I don't understand why. People stopped uppercasing HTML tags, why can't we do the same with SQL?

deleted 8y ago
[deleted]
mr_overalls 8y ago
My personal style is to lowercase SQL commands, but uppercase or initialcase objects like tables, columns, etc. for readability and minimal use of caps.
- DKnoll 8y ago
  That might only work if you came up with the schema or your collation is case-insensitive.
sbuttgereit 8y ago
First, I'm sure mere inertia plays a role, but there are practical reasons as well if you're writing more than trivial SQL queries. In most other languages you can read the statements fairly linearly, one statement leads to the next, and to the next, etc. At least within functions/methods and then you usually have indentation to help with understanding boundaries. Each "logical line" may be spread out over one or even several on-screen lines, but it's fairly easy to see the whole logical line and understand it at a glance. Not always so with SQL. If I get a complex SQL query to analyze, the first thing I do is not look for the SELECT clause (I'll usually have some sense of that before I start), but rather the FROM clause including it's JOINs and such. When keywords are uppercase, scanning the page for where in the statement to start my reading is much easier. Next I want the WHERE clause and its predicates... and finally I want to see what's being selected. So I'm not reading things nearly as linearly to understand a single logical statement like I would to understand say, a well written function. Also, single queries can be very long, so being able to jump around them where there are not going to necessarily be other cues can be important. I could be wrong, but the density of user defined names (schemas, tables, columns, etc) also is higher than in other languages, so having the keywords in uppercase makes those more spread-out statement boundaries and fewer numbers of keywords in uppercase again helps me scan the statements for those major parts as I need them. If you're writing single table queries, no sub-queries, maybe a dozen of columns or so, and only a relatively small number of WHERE clause predicates, then it might not matter much. For better or worse, that's not the world I usually find myself in :-)
- francis36012 8y ago
  Wouldn't syntax highlighting help with most of the issues you've outlined?
  - sbuttgereit 8y ago
    If I've got my developer hat on, yeah, sort of. I still find the case differences more pronounced without necessarily forcing me into a more in-my-face code formatting theme. Also, for all the reason A code format is important, the fact that I have 20 years experience with up-to-now SQL norms mean that I'm trained to look for certain things and can, almost without thinking, focus in on those with the help of historical formatting. Arbitrary changes to that history mean that now I have to discard that muscle memory and learn new ways of looking at things... I'm not sure the gain of a few less caps locks keystrokes merits forcing that learning curve. Sure the kids won't care about that because there's nothing to lose, but some of us old timers lose the benefit of our experience. But developers with good tooling to deal with more static views of the code aren't the only readers of SQL, and perhaps not the most common. With my DBA hat on, trying to figure out what's going on reading through logs and such, I don't always have that kind of tooling available. In this context the casing can help as well.... and this may form some of my bias; my first professional experiences on the application side of the world were in very much DBA roles dealing with other people's applications running on my servers. Insofar as access tools preserve developer formatting, having good "color-blind" formats made reading complex queries easier.
    - MisterOctober 8y ago
      Yeah indeed -- though I'd prefer to write all lowercase for the sake of ease, I too stick to the 'uppercasing' norms mainly to help with ease of readability -- especially in shell-only environments where syntax highlighting isn't available [e.g., using psql]
  - stubish 8y ago
    Syntax highlighting is a huge boon working with SQL, but unfortunately you often find you are working with SQL embedded as a string in some other programming language. I wonder if programming languages should have a way of specifying that a string constant contains embedded code or a template, so text editors can display it accordingly. I deal with a lot of SQL embedded in code, and prefer uppercase keywords as it seems to help me visually parse the overall file.
vbezhenar 8y ago
I never understood why people want to uppercase anything. It's like source code from 1970, when even bold highlight was something unavailable and developers used uppercase for keywords. I don't uppercase SQL, I prefer software which does proper highlighting.
- bagol 8y ago
  In the beginning, there was uppercase
  - labster 8y ago
    Originally, back in the Roman era, you had to delimit your VPDATE statements with interpuncts.
- cwilkes 8y ago
  When I see non uppercased SQL I think I’m reading it from some hipster that just discovered e e cummings and that makes me angry. Added to the fact that I’m writing SQL so I’m already angry (thanks poster above! I’m stealing that). But seriously upper case helps my eyes focus on the sql commands so that I have some sort of hand hold on the wall of text.
yebyen 8y ago
I'm with you, I prefer to uppercase the keywords only, but most SQL formatters are more liberal with their uppercasing.
Groxx 8y ago
I do the same. hand-cased words don't uniquely identify keywords or not, and more than once I've seen keywords not-upcased or column names that shadow keywords (with inconsistent upcasing), so they're inherently untrustworthy anyway. Just use syntax highlighting, which can make it unambiguous what's a keyword vs func vs name.
pletnes 8y ago
The same can be seen in the fortran community. The common factor is that both languages are case insensitive. All upper case makes no sense whatsoever.
garyclarke27 8y ago
I agree, I Write SQL code all day long, can’t explain why, I have just always hated upper case, so never used it for SQL. I also like the expressiveness of Postgres double quoted identifiers, so use these a lot in for auto generated app tables, reserving snake case for meta hand coded tables.
sgarman 8y ago
Dimitri Fontaine writes about this in Master PostgreSQL in Application Development. He agrees. I found this to be a great modern sql resource.
- morenoh149 8y ago
  If you namedrop something always link https://tapoueh.org/ https://tapoueh.org/
Semiapies 8y ago
I never uppercase the SQL keywords. If it's more than a one-liner select statement, I format it so the indentation tells me what's going on. To throw out a tossed-off example: select P.full_name, A.full_address, AT.type as address_type_name from People as P inner join Addresses as A on P.address_id=A.id where P.deleted is null
- Insanity 8y ago
  That's also my preferred approach. When formatting your code like this, the caps don't really offer an advantage anymore. Plus, it's more comfortable to type as well.
dustingetz 8y ago
it’s because if i’m writing sql, i’m definitely angry
grumpydba 8y ago
You are not alone. SQL server and sybase's system stored procedures are mostly lowercased.
coldtea 8y ago
I'm all for uppercasing the keywords and lowercasing your variables and columns. It makes for much easier reading...
danso 8y ago
I always uppercase the keywords. Maybe for short one-off queries I’ll type all lowercase. But for compound statements, readability is more important, and keywords usually are a small portion of the overall query code anyway

deleted 8y ago

[deleted]

mr_overalls 8y ago

My personal style is to lowercase SQL commands, but uppercase or initialcase objects like tables, columns, etc. for readability and minimal use of caps.

DKnoll 8y ago
That might only work if you came up with the schema or your collation is case-insensitive.

sbuttgereit 8y ago

First, I'm sure mere inertia plays a role, but there are practical reasons as well if you're writing more than trivial SQL queries. In most other languages you can read the statements fairly linearly, one statement leads to the next, and to the next, etc. At least within functions/methods and then you usually have indentation to help with understanding boundaries. Each "logical line" may be spread out over one or even several on-screen lines, but it's fairly easy to see the whole logical line and understand it at a glance. Not always so with SQL. If I get a complex SQL query to analyze, the first thing I do is not look for the SELECT clause (I'll usually have some sense of that before I start), but rather the FROM clause including it's JOINs and such. When keywords are uppercase, scanning the page for where in the statement to start my reading is much easier. Next I want the WHERE clause and its predicates... and finally I want to see what's being selected. So I'm not reading things nearly as linearly to understand a single logical statement like I would to understand say, a well written function. Also, single queries can be very long, so being able to jump around them where there are not going to necessarily be other cues can be important. I could be wrong, but the density of user defined names (schemas, tables, columns, etc) also is higher than in other languages, so having the keywords in uppercase makes those more spread-out statement boundaries and fewer numbers of keywords in uppercase again helps me scan the statements for those major parts as I need them. If you're writing single table queries, no sub-queries, maybe a dozen of columns or so, and only a relatively small number of WHERE clause predicates, then it might not matter much. For better or worse, that's not the world I usually find myself in :-)

francis36012 8y ago
Wouldn't syntax highlighting help with most of the issues you've outlined?
- sbuttgereit 8y ago
  If I've got my developer hat on, yeah, sort of. I still find the case differences more pronounced without necessarily forcing me into a more in-my-face code formatting theme. Also, for all the reason A code format is important, the fact that I have 20 years experience with up-to-now SQL norms mean that I'm trained to look for certain things and can, almost without thinking, focus in on those with the help of historical formatting. Arbitrary changes to that history mean that now I have to discard that muscle memory and learn new ways of looking at things... I'm not sure the gain of a few less caps locks keystrokes merits forcing that learning curve. Sure the kids won't care about that because there's nothing to lose, but some of us old timers lose the benefit of our experience. But developers with good tooling to deal with more static views of the code aren't the only readers of SQL, and perhaps not the most common. With my DBA hat on, trying to figure out what's going on reading through logs and such, I don't always have that kind of tooling available. In this context the casing can help as well.... and this may form some of my bias; my first professional experiences on the application side of the world were in very much DBA roles dealing with other people's applications running on my servers. Insofar as access tools preserve developer formatting, having good "color-blind" formats made reading complex queries easier.
  - MisterOctober 8y ago
    Yeah indeed -- though I'd prefer to write all lowercase for the sake of ease, I too stick to the 'uppercasing' norms mainly to help with ease of readability -- especially in shell-only environments where syntax highlighting isn't available [e.g., using psql]
- stubish 8y ago
  Syntax highlighting is a huge boon working with SQL, but unfortunately you often find you are working with SQL embedded as a string in some other programming language. I wonder if programming languages should have a way of specifying that a string constant contains embedded code or a template, so text editors can display it accordingly. I deal with a lot of SQL embedded in code, and prefer uppercase keywords as it seems to help me visually parse the overall file.

vbezhenar 8y ago

I never understood why people want to uppercase anything. It's like source code from 1970, when even bold highlight was something unavailable and developers used uppercase for keywords. I don't uppercase SQL, I prefer software which does proper highlighting.

bagol 8y ago
In the beginning, there was uppercase
- labster 8y ago
  Originally, back in the Roman era, you had to delimit your VPDATE statements with interpuncts.
cwilkes 8y ago
When I see non uppercased SQL I think I’m reading it from some hipster that just discovered e e cummings and that makes me angry. Added to the fact that I’m writing SQL so I’m already angry (thanks poster above! I’m stealing that). But seriously upper case helps my eyes focus on the sql commands so that I have some sort of hand hold on the wall of text.

yebyen 8y ago

I'm with you, I prefer to uppercase the keywords only, but most SQL formatters are more liberal with their uppercasing.

Groxx 8y ago

I do the same. hand-cased words don't uniquely identify keywords or not, and more than once I've seen keywords not-upcased or column names that shadow keywords (with inconsistent upcasing), so they're inherently untrustworthy anyway. Just use syntax highlighting, which can make it unambiguous what's a keyword vs func vs name.

pletnes 8y ago

The same can be seen in the fortran community. The common factor is that both languages are case insensitive. All upper case makes no sense whatsoever.

garyclarke27 8y ago

I agree, I Write SQL code all day long, can’t explain why, I have just always hated upper case, so never used it for SQL. I also like the expressiveness of Postgres double quoted identifiers, so use these a lot in for auto generated app tables, reserving snake case for meta hand coded tables.

sgarman 8y ago

Dimitri Fontaine writes about this in Master PostgreSQL in Application Development. He agrees. I found this to be a great modern sql resource.

morenoh149 8y ago
If you namedrop something always link https://tapoueh.org/ https://tapoueh.org/

Semiapies 8y ago

I never uppercase the SQL keywords. If it's more than a one-liner select statement, I format it so the indentation tells me what's going on. To throw out a tossed-off example: select P.full_name, A.full_address, AT.type as address_type_name from People as P inner join Addresses as A on P.address_id=A.id where P.deleted is null

Insanity 8y ago
That's also my preferred approach. When formatting your code like this, the caps don't really offer an advantage anymore. Plus, it's more comfortable to type as well.

dustingetz 8y ago

it’s because if i’m writing sql, i’m definitely angry

grumpydba 8y ago

You are not alone. SQL server and sybase's system stored procedures are mostly lowercased.

coldtea 8y ago

I'm all for uppercasing the keywords and lowercasing your variables and columns. It makes for much easier reading...

danso 8y ago

I always uppercase the keywords. Maybe for short one-off queries I’ll type all lowercase. But for compound statements, readability is more important, and keywords usually are a small portion of the overall query code anyway