I agree that "Who cares!" should be the default response here, as long as it's clear, but I think some folks (especially in engineering) think that "more rules = more clear," or "if we encode all of this information in the variable name, the variable name will always be clear," which is an error in thinking this particular article seeks to correct.
I have actually been in the throes of battle with co-workers over relaxing our variable naming standards because they are too damn prescriptive, which (in my opinion) reduces code clarity, while also setting up conflicts between those who think code should be as clear as possible in the file versus those who think that we should follow the standard even though we know it to be flawed and produce overly-verbose code.
My core argument is very much "who cares as long as it's clear" but having a specific piece of ammo where I can say "here are several arguments specifically against our current style" may convince some of these folks to loosen up a little bit. The bike-shedding is indeed ridiculous; going back and forth in Swarm for days over names for code that has fundamental algorithmic flaws. Awful stuff.
I have actually been in the throes of battle with co-workers over relaxing our variable naming standards because they are too damn prescriptive, which (in my opinion) reduces code clarity, while also setting up conflicts between those who think code should be as clear as possible in the file versus those who think that we should follow the standard even though we know it to be flawed and produce overly-verbose code.
My core argument is very much "who cares as long as it's clear" but having a specific piece of ammo where I can say "here are several arguments specifically against our current style" may convince some of these folks to loosen up a little bit. The bike-shedding is indeed ridiculous; going back and forth in Swarm for days over names for code that has fundamental algorithmic flaws. Awful stuff.