So some programmers (specially C programmers, it seems) have this terrible habit of writing very short-named variables. Then in order to understand the code, you need to decipher the meaning of each variable. Example:

```
unsigned int i, n, h, mw, my, ty;
```

This is from one of the "Suckless" projects by the way. They pride themselves in having small number of code lines so this is probably why.

and this shit did carry through Go 🥴

@AleCx04 Oh God!

@AleCx04
In Go, it's common to use 1-3 letter variable names, but only if the meaning is obvious.

@metamourge I used to use short variable names to but after a few decades I nowadays only use short names in one liners or similar, like in short lambdas with one single argument or in loops with a single content line.

All to often if a loop contains even a few lines it can grow over time snd than obvious 1-3?char variable is no longer obvious :/

C as a language is often short as in short lines and I have seen that this can foster a habit of keeping down the char count, and it was even necessary if you go back 50+ years when memory vas scares.

Using long descripting names used more memory in the compiler.

But that should not be a problem anymore, not even on things like raspberry pie and similar.

But ild habits die hard and have a tendency to spread

Well, short variable names should not affect line count so much as line length, which also is a common theme in c, keep short lines.

And to the original dev it might be obvious what they are, but that rarely translates to other devs unless it really is a common standard like x,y,z for coords and vx,vy,vz for velocity in a 3D setting.

But even then it only works if you only have a single object.

Personally I only use such names in lambdas with one or two arguments or in other one liner loops and where the variable ids declared within the loop (not using c but c# by the way)

a colleague i worked with years ago, did write quite a substantial amount of Assembly in the past. It is even worse with that. The functions are just one small blob of text. But the stuff written by that dev had an impressive performance

ah and also the files weren't large because of that

Most of the time I hear the argument: It's shorter, less keystrokes, less time.

I think the opposite is true, no matter what. Be it domain names, programming variables, documentation.

Your brain doesn't work in the same way a computer does - even when you know that e.g. "h" means "height"… your brain won't replace it whenever you see it, you need to think about it a bit, then reevaluate the context and only then things might make sense.

Abbreviations are the same problem.

Don't use them. It's highly likely that they get misunderstood.

I remember very painfully an
flamewar due to an abbreviation having two meanings - and each party consistently stating that the abbreviation was clear and needs no explanation....

It's 2020. We have terabytes of storage available, write unabbreviated clear code that needs no interpreter.

Set the line length to 120 or more as we don't have fixed 80 char displays anymore.

@IntrusionCM displays are also wide enough, so you don't need to worry about abbreviations at all. Exactly for that reason i dont abbreviate stuff anymore (in most cases even the iterator in loops is a normal word). I actually even use that 120 char width.

You have autocomplete in modern IDEs anyway

And if needed, code can be minified/obfuscated/whatever'ed later

Example like this

https://devrant.com/rants/3997897/...

https://devrant.com/rants/3968206/...

I use short names in C for typical situations because it's idiomatic and easier to read due to less clutter. Like:
i: loop index
len: length
cnt: counter
cfg: configuration
cmd: command
msg: message
sys: system
ptr: generic pointer (typically void *)
src/dst: source / destination

There's obvious of you understand the context in which they are being used, and there's obvious to the dev that wrote it. But obvious isn't always obvious.

Take for example @Fast-nop's "cnt", count was not the first word that came to mind.

@C0D4 That's a productivity test as added benefit because that only happens if you read less code than stuff on devRant. ^^

@metamourge which is, ironically, the excuse that everyone has for short variable length strings: "it makes sense!"

@Nanos

HowManyT...<TAB-AUTOCOMPLETE>

For me, the question is often one of abstraction.

If I have a sorting algorithm which applies to anything which implements the Ord(erable) typeclass, like integers, playing cards, dicks by girth, etc....

Well then inside the sort function, I will just label elements with a, b, c or something like that. If the variables are completely abstract, the name can be abstract as well.

But otherwise, descriptive names are important. I prefer to even avoid common abbreviations, I rather use lookUpTable instead of lut, user.count instead of user.cnt (that could be the user's cunt), etc. Eh, I mean, etcetera.

@Nanos I think I have a problem, I can't read all of those without issue 😔

Its_whenWeStart_getting-variable_namesLikeThis_that_iStartToCry

The common mathematician is far worse than most code golfers when it comes to one-letter variable names and unreadable code.

@Oktokolo Which is why people think math is hard. Well yeah guess what's also hard: my dick. But that's not relevant here, so the next hard thing is reading shit code, and it's hard in the same way as math.

All that horrible Fortran shit code came from directly implementing math as math goes.

I think I mostly use small variables inside iterative code, like map, reduce, sort and the like. Otherwise a one-three word variables is usually enough. You should have a pretty strong reason to go for more (Except Java Classes)

@Fast-Nop
Partially yes.

But math also tends to be the most abstract stuff you can find. Most often way more abstract than what most coders write.
For most people, understanding abstract concepts and combining them is hard.

So math would probably still be hard without the worst-possible nomenclature and coding style.

@Oktokolo

Also, Math in a higher level is mostly about proof, not methodology. I'm reading a paper on frequency analysis and the actual algorithm is only a few line, but the paper is more than 13 pages with a lot of equations and very dense explanations. With a less terse writing, I guess the amount of pages can be nearly thrice that

@IntrusionCM agreed and the brain is wonderful for parallel processing and what you read are words as concepts.

And readability beats almost everything else except for very very special cases.

@Nanos well yes, there are always lost cases in any group :P

`for (auto &v : vectors) { /* do stuff */ }`

Unless the scope of `doing stuff` grows beyond 2-3 lines I see no evil. It's idiomatic, concise, makes sense.

However, idiomatic is good for only as long as everyone knows the idiom. For me `cnt` is too much. It might be `controller`, `century`, `cunt namespace traverser` - who am I to say.

What OP quoted, though... 🤦‍♂️ ...it's not idiomatic, it's idiotic.