Hacker News Reader

Comment by AlexandrB | Hacker News Reader

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.

View on HN

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.

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.

Eye and Jay are go to as well

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/i...

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.

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.

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.

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.

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

* E=m*c^2

Or:

* process_control_setting = proportional_component + integral_component + derivative_component

* q=p+i+d (for those of us who know PID control)

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.

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'."

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

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

Reply on news.ycombinator.com