I feel like a complete weirdo when it comes to comments and variable names. I've never worked professionally as a coder, but I've been working with python and a bit of js for like 15 years now. I strongly believe that variable names should be long, and explain what they are, and that comments should be long, and explain what's happening.

I have no idea why people want to "save time" to write short comments and short variable names. I just CTRL+C, CTRL+V my variable name anyway. They compound on each other, and that ends up adding an unnecessary level of complexity, and the possibility for errors.

When I come back to a piece of complex code after a year or two, I'm very, very happy that I've used a variable name like "three_tuple_of_weight_radius_price" instead of "tuple" or "t".

▲

zahlman 3 days ago | parent | next [-]

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

▲

rasmus-kirk 3 days ago | parent | prev | next [-]

I think it's a leftover before proper LSP's, if you had to type/paste everything, that would be fairly tedious, but now-a-days everyone uses LSP's with autocomplete that have all the variables in scope.

I do think very long names can hurt readability though so it's still a balancing act, but variables like "t" (often used in Haskell, ugh) is awful in my opinion.

▲

3 days ago | parent | prev | next [-]

[deleted]

▲

gavmor 3 days ago | parent | prev [-]

"tuple" is entirely redundant with the types, though.

▲

scoofy 3 days ago | parent [-]

I’m not sure what you mean. You’re not necessarily going to know the type of a variable just by reading a random section of code… especially in Python.

I absolutely going to add the type to the variable name if it’s a complex function. It’s just clearer.

▲

zahlman 3 days ago | parent [-]

The point is to not care about the type. If you see `weight, radius, price = ...`, then it generally isn't going to matter whether `...` is a tuple or a list (or more exotic possibilities). What matters is that you can iterate over it, and iterating over it gives exactly three results, and the first result represents a weight, etc.

If your weights need to be, say, a floating-point number of kilograms, then you establish that convention, and only mark intentional deviations from the convention (e.g. because you're doing an explicit conversion to format output). (Or you use a library like Pint to give more formality to it.)

▲

scoofy 3 days ago | parent [-]

Lists are mutable, tuples are not… that’s a massive difference if I’m editing code deep in a function I wrote two years ago.

▲

zahlman 3 days ago | parent [-]

The point is that you clearly aren't mutating it in the current context. Therefore, knowing that you could mutate it doesn't help you understand what the current code is doing, nor guide you away from mistakes (as you would have no reason to try to mutate it).

	▲	scoofy 3 days ago \| parent [-]
		I operate a site where I have lists of things that have operations done on them all the time, occasionally I’ll load those series into memory as a tuple to save memory. If I’m adding a feature to the site in 5 years, it’s going to be important to know if I’ve done that or not.