Hacker News new | ask | show | jobs
by jolmg 2336 days ago
> editors colorize keywords so they stand out

Not when it's embedded as a string in another language, like when the query you want is not supported by the ORM.

> Lowercase is objectively more readable

No, and definitely not objectively. I generally don't capitalize my SQL, but I can't argue that using lowercase exclusively makes the SQL more readable. It definitely does help readability to differentiate SQL keywords from table and column names. Compare:

  select
      region_fleet,
      case when status = 'delivered' then 'delivered' else 'not delivered' end as status,
      date_trunc('week', day) as week,
      count(distinct row(day, so_number)) as num_orders,
      count(distinct case when scheduled_accuracy_meters <= 500 then row(day, so_number) else null end) as num_accurate,
      avg(scheduled_accuracy_meters) as scheduled_accuracy_meters
  from
      deliveries
  where
      ...
  group by
      1, 2, 3
with

  SELECT
      region_fleet,
      CASE WHEN status = 'Delivered' THEN 'Delivered' ELSE 'Not Delivered' END AS status,
      DATE_TRUNC('week', day) AS week,
      COUNT(DISTINCT ROW(day, so_number)) AS num_orders,
      COUNT(DISTINCT CASE WHEN scheduled_accuracy_meters <= 500 THEN ROW(day, so_number) ELSE NULL END) AS num_accurate,
      AVG(scheduled_accuracy_meters) AS scheduled_accuracy_meters
  FROM
      deliveries
  WHERE
      ...
  GROUP BY
      1, 2, 3
It makes the column names stand out when you lack color hints. You can quickly skim to see what data is involved in a query without visually parsing the expressions.
5 comments

The first is actually much easier to read, and lower case is far superior.

Lowercase letters are read and comprehended faster: https://ux.stackexchange.com/questions/72622/how-easy-to-rea...

Additionally using casing when it has no meaning is an anti-pattern.

That link talks in general. In general, I agree that lowercase is more readable.

> Additionally using casing when it has no meaning is an anti-pattern.

Why do you say that it has no meaning? This is about differentiating SQL keywords from table and column identifiers. That's the meaning.

> The first is actually much easier to read, and lower case is far superior.

Reading the query whole, sure, but are you seriously suggesting that you can skim for the identifiers faster in the all-lowercase one when there are no color hints?

>Why do you say that it has no meaning? This is about differentiating SQL keywords from table and column identifiers.

One could also type like `CoUnT(dIsTiNcT CaSe WhEn ... EnD)` to make the keywords stand out. Casing has absolutely no meaning in SQL outside of single quotes.

On the other hand, (in python for example) SOME_FUNCTION() and some_function() both have meaning. They do not refer to the same thing.

>but are you seriously suggesting that you can skim for the identifiers faster in the all-lowercase one when there are no color hints?

Yes. Especially since my eyes don't get stuck on the massive blobs of ALL CAPS YELLING TEXT in the select.

> One could also type like `CoUnT(dIsTiNcT CaSe WhEn ... EnD)` to make the keywords stand out. Casing has absolutely no meaning in SQL outside of single quotes.

That the language doesn't enforce a meaning doesn't mean that we can't add meaning to the casing. This is like how in multiple languages it's convention to write constant variables in all-caps even though few languages enforce it.

That's a fantastic example because an all-caps constant actually does have a different meaning than the same word spelled in lowercase, and all the more reason to not capitalize keywords in SQL (Structured Query Language, being an acronym, is proper to capitalize)
Could you fill out the following sentence, please?

When an identifier is written in all-caps, it generally _____ that it's a constant.

I feel like you're just, in bad faith, refusing to acknowledge that the word "meaning" doesn't have to be in any way related to language enforcement. Are you trying to argue for the sake of arguing?

For what it is worth, I find the first of those (i.e. the lowercase one) much easier to read.
Yeah, but how about this:

select region_fleet, case when status = 'delivered' then 'delivered' else 'not delivered' end as status, date_trunc('week', day) as week, count(distinct row(day, so_number)) as num_orders, count(distinct case when scheduled_accuracy_meters <= 500 then row(day, so_number) else null end) as num_accurate, avg(scheduled_accuracy_meters) as scheduled_accuracy_meters from deliveries where ... group by 1, 2, 3

vs.:

SELECT region_fleet, CASE WHEN status = 'Delivered' THEN 'Delivered' ELSE 'Not Delivered' END AS status, DATE_TRUNC('week', day) AS week, COUNT(DISTINCT ROW(day, so_number)) AS num_orders, COUNT(DISTINCT CASE WHEN scheduled_accuracy_meters <= 500 THEN ROW(day, so_number) ELSE NULL END) AS num_accurate, AVG(scheduled_accuracy_meters) AS scheduled_accuracy_meters FROM deliveries WHERE ... GROUP BY 1, 2, 3

... because a lot of time, when these nicely-formatted statements get parsed, the whitespace gets condensed, and when it gets spit out in an error message, I for one would like the all-caps keywords to be landmarks to direct my eye.

I still find the first one more readable.

Maybe it's just me, or maybe it's a matter of habit, but for me the changes from lowercase to uppercase and back are a kind of hurdle that make my brain pause a moment. The second example is much more cumbersome to me to read and parse.

Same for me - I find the use of upper case keywords like this jarring in SQL. It seems quite old-school, like reading COBOL!
It's probably my repressed memories of FORTRAN that cause me to react so strongly to UPPERCASE.
Some editors do syntax highlight "language injections" or SQL embedded as a string. e.g. Rider by JetBrains: https://blog.jetbrains.com/dotnet/2018/10/29/sql-inside-c-st...
What do you think about only capitalizing the first letter like this:

  Select
      region_fleet,
      Case When status = 'Delivered' Then 'Delivered' Else 'Not Delivered' End As status,
      Date_Trunc('week', day) As week,
      Count(Distinct Row(day, so_number)) As num_orders,
      Count(Distinct Case When scheduled_accuracy_meters <= 500 Then Row(day, so_number) Else Null End) As num_accurate,
      Avg(scheduled_accuracy_meters) As scheduled_accuracy_meters
  From
      deliveries
  Where
      ...
  Group By
      1, 2, 3
The 2nd shouts at me from all angles, maybe a side effect from being hounded by netiquette police in forums.