Hacker News Reader

Comment by lifthrasiir | Hacker News Reader

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.

View on HN

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.

> anOverlyLongAndInformationFreeIdentifier

Apple has one 82 characters.

https://developer.apple.com/documentation/contacts/cnlabelco...

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.

And I would say that’s a good case where the long name is meaningful and necessary.

On the other hand when you are dealing with a file pointer in a language that deals with file pointers constantly, “fp” is meaningful enough.

CNLabelContactRelationBiaoMei would have been a lot better. People can look up what that means when they need to.

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.

Exactly: one option is a single-time, fixed cost (single-time-ever if you write it as:

  CN_LCR_BiaoMei = 77,
  // either mother's sibling's daughter or father's sister's daughter
  // aka female cousin involving at least one female parent

), while the other adds a constant tax on all uses of the variable (well, constant in this case) in perpetuity.

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.

You have to worry about discoverability the other way: how would I (dumb american) know that's something I should be worried about?

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].

[1] https://news.ycombinator.com/item?id=37607801

Reply on news.ycombinator.com