There should be naming guidelines just like how a team should have style guidelines.
The discussions should happen when creating (or updating) these guidelines.
Then these guidelines should be followed, no need for long discussions during code reviews.
Variable name does not follow guidelines => Mark it as an issue, defer to the guidelines move on.
Some people will just find it as an excuse to go all over it the naming issue. Worse than the "80 columns is the limit" people, because after all 80 columns is 80 columns. But there's no "ideal name" for some people.
No. The purpose of a name is to convey meaning to the reader. There is exactly one valid complaint about a name: “I’ve read this carefully and I still don’t know what it means.”
A standards-compliant name that interferes with understanding is not okay. A name everyone gets, which happens to not follow a rule in some rulebook, is probably fine.
Use a good name and be done with it. You're naming a variable, not the title of your Magnum Opus.
Edit: I think people are reading too much into the initial dismissiveness and not going past the 1st line.
More important than picking the perfect name:
- Being consistent with the naming (you called it a 'bolt' keep calling it a 'bolt' for the same type of object and for its life through the code path. If bolt is not a great name you can change later.
- Being easy to remember and type. There's no point with TurningWheelThatGoesSqueak and having a TurningWheelThatGoesSquak and a TurningWheelThatGoesSquewk this will only make the developers go crazy. Simplify.
And yes bikeshedding is bad. I just find it too ironic that parent's username reminds me of the place that took bikeshedding to the extremes.
Any extreme of naming is bad. Spent zero time thinking about naming and you end up with a codebase where the same thing is called differently depending on how the person felt that day. Or core data structures are called "node", "element" or "link", words that are already overloaded and should be avoided.
On the other extreme, thinking too far about naming leads into bikeshedding and no work getting done.
So as with many other things, balance is the thing that gets you the furthest.
You're naming a variable, not the title of your Magnum Opus.
You're naming a variable, and that name is probably the most important documentation about that specific point in the code. A lot of the time a useful name will be quite obvious, so you should use one. If you see code that has variable names like a, i, myVar, value, etc then it's usually a sign the developer didn't think very hard about the code that they were writing. Using a name that gives some context to the data the variable should hold is massively useful to the next developer to work on the code (which is usually you, so you'll be thankful you did).
Except they're not as good as 'index', which is obvious and provides some meaning, so why accept single character name?
I have an eslint rule that blocks single character var names on my projects. It makes my team develop good habits, and no one has ever complained about it. Our code is very readable.
Are you awful or just trolling? I've said that naming is very important, but I didnt't suggest that people should choose a longer word when two are equivalent. A real way to give 'more meaning' to the index is to indicate to which collection it belongs.
Sometimes the failure at finding a good name (and taking 30 minutes to name your variable) means your abstraction is not good and/or your variable encloses multiple concepts.
Of course, a short-spanned internal-only variable used just once or twice doesn't deserve a 30-minutes debate; OTOH a public variable which could be externally exposed by a class could require a bit of thinking.
Elements of Clojure is an excellent book that goes through what a good name is and what it should represent. Don't be put off by the "Clojure" in the title, the book is really not about Clojure but about programming, using Clojure for its samples.
