4 ms·

Character count is a valid argument because a human is going to have to read the code at some point. Otherwise, Java style names like "countriesFromAsiaWhereAre

Character count is a valid argument because a human is going to have to read the code at some point. Otherwise, Java style names like "countriesFromAsiaWhereAreTheMostPlanesAndBoats" would be just fine. Edit: I don't get the hate for "i" or "j" as increment variables. When you're working with numerical data they closely match how you would express the same operation with mathematical notation and are idiomatic to the point that everyone with non-trivial experience in programming knows what they represent. There are better options in some cases (e.g. "for name in names:"), but there's nothing inherently wrong with i, j, k, etc.

Larrikin 2y ago
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?
NAHWheatCracker 2y ago
At my last job, there was a frontend developer who added a linter rule that variable names must be at least 2 characters long. The project already had 20,000 lines of code. Every time anyone made a change to a file, they would have to rename all the one letter variables. Usually, this meant all the for loops in the file. I tried to explain how pointless this rule was, but he wasn't having any of it. Most people just renamed variables like i > ii, which was worse.
- deleted 2y ago
  [deleted]
- morkalork 2y ago
  What is even the point of digging in deeper, did they not see everyone around them doing the i>ii workaround? You've lost, call it a failed experiment and move on.
- tomrod 2y ago
  Eye and Jay are go to as well
- johnny22 2y ago
  a good linter rule would have exceptions for loop variables by context by just by name like i, j, k. Often just by name is good enough at least for a solo dev or small team. I require them to be at least 3 chars EXCEPT those. For example: https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-length.html#cmdoption-arg-IgnoredLoopCounterNames https://clang.llvm.org/extra/clang-tidy/checks/readability/i...

Larrikin 2y ago

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?

NAHWheatCracker 2y ago

At my last job, there was a frontend developer who added a linter rule that variable names must be at least 2 characters long. The project already had 20,000 lines of code. Every time anyone made a change to a file, they would have to rename all the one letter variables. Usually, this meant all the for loops in the file. I tried to explain how pointless this rule was, but he wasn't having any of it. Most people just renamed variables like i > ii, which was worse.

deleted 2y ago
[deleted]
morkalork 2y ago
What is even the point of digging in deeper, did they not see everyone around them doing the i>ii workaround? You've lost, call it a failed experiment and move on.
tomrod 2y ago
Eye and Jay are go to as well
johnny22 2y ago
a good linter rule would have exceptions for loop variables by context by just by name like i, j, k. Often just by name is good enough at least for a solo dev or small team. I require them to be at least 3 chars EXCEPT those. For example: https://clang.llvm.org/extra/clang-tidy/checks/readability/identifier-length.html#cmdoption-arg-IgnoredLoopCounterNames https://clang.llvm.org/extra/clang-tidy/checks/readability/i...