5 ms·

But that's a ridiculous example you're proposing in bad faith. I flag nearly all abbreviations in code reviews because code is meant to be read and the names o

But that's a ridiculous example you're proposing in bad faith. I flag nearly all abbreviations in code reviews because code is meant to be read and the names of things should be clear.

AlexandrB 2y ago
It's not in bad faith to say that there's a cognitive load to having longer line lengths or, god forbid, wrapped lines when you're trying to figure out what the code is actually doing with that data the variables represent. Obviously the Python "except" case being discussed is not a big deal in this regard, but you made a blanket statement about character count being no big deal because of big hard drives and IDEs.
lostdog 2y ago
How about abbreviating the 12 most common things in the codebase, but everything else is long? That's a nice compromise where you need to learn a few core concepts, but the code itself is easier to scan for bugs in a lot of places.
School-Cotton 2y ago
I work on code that uses `pid` pervasively, and it would drive me crazy if someone insisted I write out `processId` every time. Same with `tx` or `rx` for channel endpoints, `i` for loop variables, `txId` or `tid` for transaction ID in databases, etc. If something is very common in the domain you're working in it's more annoying _not_ to abbreviate it.
- Kim_Bruning 2y ago
  In certain contexts, I'm ok with eg (off the top of my head): * x, y, z (coordinates) * r, g, b, a; c, m, y, k; y, u, v (colors) * i, j, k matrices and such * p, i, d; Kp, Ki, Kd in process control * rv (return value), where it is clear what The Thing To Be returned is. * common variables from eg physics Generally because these are well known and defined in particular contexts. I don't always make it, but sometimes an argument can be made that single letters are better known/recognizable by their single letter name. Compare: * total_energy = mass * light_speed_constant ^ 2 vs * E=m*c^2 Or: * process_control_setting = proportional_component + integral_component + derivative_component vs * q=p+i+d (for those of us who know PID control)
- fwip 2y ago
  Recently, I saw somebody writing that in their projects, they define a Glossary.txt of terms, and then set up their tooling to flag any use of an identifier that isn't a word or defined in the Glossary. (Allowing also for compound words like camelCase and snake_case, of course). So in their project they could define `pid: process identifier [...]`, and then their tooling would be allow a variable named `new_pid`. Upsides: consistent vocabulary in your project, a centralized place to look up jargon, and a subtle friction to avoid adding new terms that people might not immediately grok. I wish I could remember the source; because it sounded like a nice setup to steal.
- kstrauser 2y ago
  That "in the domain" bit is an excellent callout, and I'm stealing it. "Why don't you write out 'process_id'?" "Because the people who maintain the sort of code that cares about pids all refer to it as 'pid'."
xorcist 2y ago
So you intentionally make code harder to read for most of the humans on this planet, so satisfy a desire to use longer identifiers?
tsimionescu 2y ago
So your code is full of HyperTextTransferProtocolSecureClients, using a TransportLayerSecurityCertificate?

But that's a ridiculous example you're proposing in bad faith. I flag nearly all abbreviations in code reviews because code is meant to be read and the names of things should be clear.

AlexandrB 2y ago

It's not in bad faith to say that there's a cognitive load to having longer line lengths or, god forbid, wrapped lines when you're trying to figure out what the code is actually doing with that data the variables represent. Obviously the Python "except" case being discussed is not a big deal in this regard, but you made a blanket statement about character count being no big deal because of big hard drives and IDEs.

lostdog 2y ago

How about abbreviating the 12 most common things in the codebase, but everything else is long? That's a nice compromise where you need to learn a few core concepts, but the code itself is easier to scan for bugs in a lot of places.

School-Cotton 2y ago

I work on code that uses `pid` pervasively, and it would drive me crazy if someone insisted I write out `processId` every time. Same with `tx` or `rx` for channel endpoints, `i` for loop variables, `txId` or `tid` for transaction ID in databases, etc. If something is very common in the domain you're working in it's more annoying _not_ to abbreviate it.

Kim_Bruning 2y ago
In certain contexts, I'm ok with eg (off the top of my head): * x, y, z (coordinates) * r, g, b, a; c, m, y, k; y, u, v (colors) * i, j, k matrices and such * p, i, d; Kp, Ki, Kd in process control * rv (return value), where it is clear what The Thing To Be returned is. * common variables from eg physics Generally because these are well known and defined in particular contexts. I don't always make it, but sometimes an argument can be made that single letters are better known/recognizable by their single letter name. Compare: * total_energy = mass * light_speed_constant ^ 2 vs * E=m*c^2 Or: * process_control_setting = proportional_component + integral_component + derivative_component vs * q=p+i+d (for those of us who know PID control)
fwip 2y ago
Recently, I saw somebody writing that in their projects, they define a Glossary.txt of terms, and then set up their tooling to flag any use of an identifier that isn't a word or defined in the Glossary. (Allowing also for compound words like camelCase and snake_case, of course). So in their project they could define `pid: process identifier [...]`, and then their tooling would be allow a variable named `new_pid`. Upsides: consistent vocabulary in your project, a centralized place to look up jargon, and a subtle friction to avoid adding new terms that people might not immediately grok. I wish I could remember the source; because it sounded like a nice setup to steal.
kstrauser 2y ago
That "in the domain" bit is an excellent callout, and I'm stealing it. "Why don't you write out 'process_id'?" "Because the people who maintain the sort of code that cares about pids all refer to it as 'pid'."

xorcist 2y ago

So you intentionally make code harder to read for most of the humans on this planet, so satisfy a desire to use longer identifiers?

tsimionescu 2y ago

So your code is full of HyperTextTransferProtocolSecureClients, using a TransportLayerSecurityCertificate?