If you’ve seen any amount of Go and Java code (starting with, say, the standard libraries), you’d know these communities take very different approaches to variable names.
The point is that you do not choose the way to name variables based on a sheepish "it's the way the community does it".
You're responsible for your own code, and your organisation's code. It has nothing to do with the language.
I know the point you're making, but I don't think it's very convincing.
First off, OP is talking about a trend in the community to favor shorter and shorter names. He didn't say you need to code that way, but there is an increasing chance that the programmers you work with, or the libraries you depend on, will have adopted this convention.
Second, unless you are coding in a vacuum or starting a brand new project, you're usually expected to follow the conventions of an existing codebase. These were likely influenced by conventions in the community, which often are set by conventions in the standard library, which have much to do with the language.
But then you end up with a non idiomatic coding style, which may be an issue if your code is open-sourced. I'd be very wary of a Java program where variable names are snake_cased, for instance: did they do it for a good reason? Are they just beginning java developers? Will I run into other ad hoc coding practice when trying to understand/maintain/extend their code?
"Poor naming" is subjective. What is the correct name for a variable that associates a user's name with its configuration profile? userNameToConfigurationProfile? user_name_to_configuration_profile? userToConfig? profiles? userCfg?
If there was one true way to do it, everybody would adopt it (unless you consider some communities are just plain dumb).
