I was following a course on full-stack Svelte that uses knex for queries. The author, who is kind and wants to help the audience, suggests using knex-stringcase to convert database column names from snake_case to camelCase. This, according to the author, will make the code “a little bit more understandable for JavaScript developers”. This is deeply misguided:

1. You are calling the exact same thing with two different names:
   • You have to use one spelling whenever you are near SQL (e.g. schema migrations in JavaScript itself, SQL queries that maybe your query writer cannot generate, SQL queries from other systems)
   • You have to use the other spelling most of the time when you are in JavaScript
2. You have to remember those facts every time you are near those names (e.g. coding, tests, searches, comments, documentation, speech if say you need to spell it to another programmer during a pairing session, and so on)

The “benefit” of all this effort is that instead of writing anObject.some_value you get to write anObject.someValue:

const result = knex("some_table")
  .where({ some_value: "xyz" })
  .select("some_other_value")
for (let row of result) {
  console.log(row.someOtherValue)
}

The “benefit” is thus that you end up referencing the same value by two different names all over the place. How is this not counterproductive? I find this fetishization of different spellings very strange.

By the way, there is another, simple, obvious way to achieve the same spelling in the entire system: name the tables and columns with camel case as well! Who says that you have to use snake case in SQL? Where is that written?

But before you run off to do that, I have to warn you that, armed as I was with that conviction, I first fired off a sample query on Postgre:

create table camelCase (
  camelCaseId varchar(50)
)

And (of couse) it disappoints by converting camelCaseId to its own inane spelling camelcase. :facepalm:

Apparently this is what you have to do to have it heed the actual spelling:

create table camelCase (
  "camelCaseId" varchar(50)
)

And because Postgre is too clever you can even do this:

create table camelCase (
  "camelCaseId" varchar(50),
  camelCaseId varchar(50)
)

I understand the case (ahem) for the “case-insensitive” but how is automatic conversion to lower-case helpful to anybody? You still have to account for the (apparently masochistic?) few that will use "camelCase" so you cannot even count on lower-case always being true.

This is the same coddling that we get when languages, SDKs, frameworks and products are gearded for “hello world” level of example rather than for production and years of maintenance with changing teams. But by the looks of it I’m likely, once again, on the wrong side of the history.

Last modified on 2021-05-08