> I have no idea why people want to "save time" to write short comments and short variable names

Really long variable names put extra space between the operators and calls, which makes it harder to grok the logical structure of the expression. When I write `a + b` in code, it's in that order because the language demands it, and I use languages with that syntax for reasons of familiarity; but really, the `+` is the most important thing there, so it shouldn't be buried way off to the right.

I don't like for variable names to mark type. `weight_radius_price` is fine (and usually much better than `wrp`, and definitely much better than `tuple` or `t`) but a) we know it's a 3-tuple because we can see the right-hand-side of the equals sign; b) the structure of the name already conventionally tells us to expect more or less that (although maybe a class or structure abstraction is missing?); c) the choice of a tuple is probably not really relevant in context as compared to other ways of sticking three atomic values together.

▲

scoofy 3 days ago | parent [-]

> we know it's a 3-tuple because we can see the right-hand-side of the equals sign

In the context I’m referring to, the variable may have been set 80 lines earlier, 7 years ago, when I was worse at coding.

▲

zahlman 3 days ago | parent [-]

I mean, good habits tend to compound each other.

	▲	scoofy 3 days ago \| parent [-]
		I think this response misses the point. Yes, if I’d not been worse at coding a decade ago, I wouldn’t be revisiting the code in the first place. The point of the redundancy of very clear, descriptive variable names, is that the code is going to suck tomorrow, even if it is good today. Future me is always going to look down on today me. The difference is that I planing for that, so maybe I can help out future me by being verbose, even if it isn’t necessary for much of the code that ends up being fine. When I have a nasty bug, I don’t want to waste a day on something that could have been clear if I’d just explained it properly.