I'll be honest, this code is easier to read for me without the comments. Also sorting feels like it's going to be slower than having some kind of set structure? You don't need ordering, just collocation of duplicates. If not or if it's a wash, that is also a good thing to comment. Also I'm not sure about the semantics of Go but it seems this mutates the argument AND returns a value, something I consider dangerous.

Otherwise I agree, people have a weird hang up about short variable names. Somehow not a problem in mathematics...

▲ jbreckmckye 4 days ago | parent | next [-]

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.

	▲	alembic_fumes 4 days ago \| parent [-]
		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.

▲ 4 days ago | parent | prev [-]

[deleted]