Comment by zero_shift | Hacker News Reader

Comment by zero_shift | Hacker News Reader

Parent Full thread

There's probably a better example. The point is sometimes the What needs explanation, and finding a better What isn't practical.

I have slightly unorthodox opinions about short variables. I used to hate them. Then I posted a question on one of the PL design forums - it might have been Reddit r/programminglanguages - why is there are history of single letter names for type variables? ie T, U, etc for generics. The answer I got back, was, sometimes you want code to focus on structure rather than identities. That stuck with me, because it helped me understand why so much C code (including Linux) code uses similar naming practices. Names can lie, and sometimes expressing the structure is the absolute critical thing.

Back when I programmed in Haskell, I also had a similar question about the extremely terse variable names that pop up everywhere. I'd wonder, why is this "x" and "xs" instead of "item" and "items" or "businessName" and "businessNames" or whatever. Eventually I found this (paraphrased) answer that made it all click:

The specificity or abstractness of a (variable) name relates to the values that it can hold. So when you have a very abstract function whose inputs can be of almost any type, naming those inputs in an overly-specific manner is an exact inverse of the failure of giving an overly generic to name highly constrained parameter.

Examples of correct naming:

  func firstWord(s string) string { ... }

  func bidShortcodePrefix(businessId string) string { ... }

Examples of incorrect naming:

  func firstWord(strWithOptionalSpaces string) string { ... }

  func bidShortcodePrefix(s string) string { ... }

All this said, I do agree with your original take on the comments. I much prefer having human-readable explanations inline with anyhow non-trivial code. If nothing else, they really make it easier to correctly fix the code if a bug is found much later.

Reply on news.ycombinator.com