3 ms·
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.
by xyzelement 3y ago
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.
- a1369209993 3y agoExactly: 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.
- School-Cotton 3y agoYou can apply this logic to anything. If you were working on database software, would you make a variable transactionId or idOfGroupOfStatementsThatMustBeExecutedAtomically ?
- xyzelement 3y agoI 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.
- School-Cotton 3y agoIf 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.