Maybe your tangent is pointing at a wrong direction, because I think there are also a sizable portion of such programmers in many other languages. It seems that anOverlyLongAndInformationFreeIdentifier is widely despised, but once names do have enough information contents, an exactly preferred name wildly varies even in a single code base. For example induction variables in Python generators tended to be shorter than average in my experience.
This is particularly true in statically typed languages that require a type declaration. Here’s some go:
func copy(f *os.File) { … }
I think f is more than clear enough as a parameter name. The same can be said of variables where the type is easily inferred from the declaration or initialization.
I once worked with safety critical code that had a variable name 62 characters long, without any extra fluff. It made sense in context. The problem was disambiguating it from the other half-dozen similarly-named, almost as long variables. At times I resorted to diff to verify that two variables were, or were not, the same one. Good times.
I haven't been a dev in a bit, but I'd say between having a longer variable name, and having to crack open the fucking dictionary.... I have a clear preference.
You can apply this logic to anything. If you were working on database software, would you make a variable transactionId or idOfGroupOfStatementsThatMustBeExecutedAtomically ?
I was thinking along these lines when I wrote my post... I think there's some domain knowledge that can be expected. A DB dev is probably expected to know what an "id" is. But probably 99.9999999% of devs even working with the address book APIs can't be expected what to know what "BiaoMei" is unless they are Chinese to begin with.
If you're working in a domain when you need to care about Chinese kinship relationships then it's just as reasonable to expect you to know what "biao mei" means as it is to expect a DB engineer to know about transactions.
It is not information-free though. It describes what it actually is, and no one could agree on a shorter and unambiguous term. I personally prefer `CNLabelContactRelationBiaoMei` just in case [1].
