Way to open up a constructive discussion ;)
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, 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).
You can always read the context and see 'for value in list_of_values' or understand what's it that you're working with right now.
Yes, be more explicit on the tricky parts, but sometimes i = i+1 is just fine.
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.
Because readability suffers with repeated long variable names
There's a reason why math uses i,j,k and x,y,z and it's not to be petty.
Even in the meta-sense it is being discussed here.
There is something about naming that we like thinking about, and fine tune our thoughts on, more than a simple need for legibility.
There is a sense of ownership in picking a name.
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.
You can read a sample chapter online, which is the chapter about naming. Highly recommended! https://leanpub.com/elementsofclojure/read_sample
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.