This came up at my work Christmas party. One colleague on my team (1) hates my reviews because the naming things I point out are way too pedantic. Another colleague (2) in our same team loves my reviews because it makes them think about how it's read and understood.

It's difficult to convey why naming is important. (1) also feels that the code needs a lot more comments and berates others for not commenting their code. I have a hard time pointing out the irony to them.

One thing that I've found over and over again, is that if something is hard to name, there is often a problem with the abstraction itself. Most common issue is that the thing that resists naming is doing multiple things and that it should be split up in smaller parts that focuses on something small that can be simply named.

I've also discovered that the problem with the abstraction itself that the naming difficulty is pointing out might be the mere fact that this abstraction exists in the first place.

We've got such a fetish for reusability that it often overwhelms any care we might have given to comprehensibility.

I usually find in every project that there are few terms that are overloaded to mean multiple conflicting things.

On one project it was so bad that every time a particular word was used in conversation I had a mini freak out because it essentially referred to six related but very distinct things. I had to figure out which one people meant, assuming they even knew themselves.

It wasn't like these things were subtypes of that word either. The word had just been bastardized beyond recognition.

I tried to make up six new meaningful names and "ban" anybody from using the original word but it didn't stick particularly well. We never did manage to exorcize the original word from the code base, so it hung around misleading people.

It did lead to bad abstractions but the root of the problem wasn't the abstractions themselves but the fact that this word was used so indiscriminately and inappropriately.

And this is why code reviews while helpful can be wasteful. Reviews should be based on existing standards not preferred methods of each reviewer. Some people feel they need to comment so they over comment. Some feel they need to prove how much they know. Others may mark you down for doing it how the previous review recommended.

i found that even with existing standards, some people use to adapt the meaning to their own ends because either what they think are ALWAYS right or they really just don't care.

> but let’s not stop calling ... the database temmp_v3_old_Udpate_RstdnewV2

I worked briefly on a codebase that was otherwise produced by Chinese programmers (in China).

It did feel somewhat surreal seeing variable names that were in English but misspelled, particularly when e.g. several classes all had a field of the same name, except that in one of them, the name was misspelled.

I assume it didn't bother them because (a) they weren't English speakers anyway, and (b) they autocompleted everything. Why would it matter that `update_history` happens to be spelled `udpate_history` in one out of five classes? You just type `u` and pick the right field.

I've seen the same thing many times with English-speaking programmers. Plenty of people just don't spot that 'udpate_history' is misspelt.

And sometimes that mistake propagates and leaves us 25 years later still using referer [0]

[0] https://annaken.github.io/a-brief-history-of-the-referer-hea...

This one always seemed to me like a plausible alternative spelling (cf. traveler for traveller).

Maybe the reviewers who let this through were speakers of British English who knew it was misspelt but conceded it without a fight, having already lost on color, gray, center...

Traveler is stressed on the first syllable; referrer is not.

This is me.

The invention of the symbol name spellchecker a decade or so back has been a wonderful boon for me. It's a little annoying to teach it the new jargon when I'm getting started in a new codebase, but it's easily a net time saver. Catching spelling errors when you first create the new symbol is always cheaper than fixing them after it's being referenced from 15 different files and can't be fixed without another code review.

I used to think descriptive variable names were a waste of time (a,b,c, even things like booya, foo, etc), until I had to maintain my own code from years ago. I literally had no one to blame but myself for the extra deciphering work I had to do.

Naming is simple when the function or method is simple.

Complex naming is often, but not always, a good indicator of complexity.

Unless of course, it's Java... https://projects.haykranen.nl/java/