[moloch-hai]

This is a ridiculous thing to have to discuss. Probably it is a product of software development's version of the "Homeowner's Association", Code Review, where petty rule enforcement is allowed to overrule good sense.

The essence of a name is twofold: it identifies a thing, and distinguishes it from every other thing. Anything that achieves these two ends is a good name.

Where there is only one thing, its name doesn't matter: only language syntax demands it have a name at all. Shortest is best. In some languages, "_" is that name.

Where there are only two, you need two names visibly distinct. The easiest and cleanest way is two one-letter names.

Using longer names lets you provide documentation without adding a comment which could later become incorrect. That is the only value in a longer name. A longer name has a cost that has nothing to do with how long it takes to type: the reader has to read it to determine it is this thing and not that. It squanders readers' attention. It is worst if it is similar to another name.

If you want to use talking about names in code review to make code better, pay more attention to names that are too similar than to short names.

[techsin101]

At first I thought you were arguing against the point I made, but after reading this fully I totally agree. The worst offenders that are hell bent on naming variables as sentences are java developers. For some reason the boiler plate required by Java is no long enough for them. Lol. Joking aside, I think anywhere where the code is an API for external functions or anything like that. Having a very descriptive name and consistent convention is good, also if the variable is being carried over in a nested code or is being passed around or is being used 50 lines down somewhere then it is useful to name it in a way that is recognizable

Ultimately, I think even the choice of naming something and using a single letter communicates your intentions. If you make something a single letter then you're telling the reader that do not even worry about this variable it is just passing through, but if you need something your communicating your intentions of using this variable in the future it is more permanent in a sense

[moloch-hai]

Right! Anywhere you are offered a choice about what to write, you can use that choice to communicate something. Best is when the message comes through without need to read text.

Whitespace is such a choice. Used judiciously, whitespace and its absence can call attention to organizational choices. Used injudiciously, it loses all useful meaning. People who splatter whitespace everywhere -- a blank line above and below every line of code, every parenthesis with a space before and after -- communicate only their contempt for the reader.

[sublinear]

> ... pay more attention to names that are too similar than to short names.

Ah this is exactly why people dislike the short names.

If you ever have more than a few of them and they aren't even real words, common abbreviations, or hijack well known unreserved names I would immediately reject that during code review.

I think most people are fine with plain English 1 to 3 word names concatenated in whatever style of the language or other conventions.

i.e. "result" instead of "r", "re", or "res"

Why? Because "r" is familiar as a read permission, "re" is familiar as a regular expression, and "res" is familiar as a response object.

This is the bad kind of familiarity that drives people up a wall and wastes a ton of time.

[moloch-hai]

Keep control of syllables. Each counts against your cognitive limit of "seven plus or minus two" items that fit in registers.