and that’s yet another way to end up with hard to read code.
Variables hold values that have meaning. Learn how to name things and you’ll write good code.
edit: someone just wrote an article along these lines. The only thing I’d change is the cause-effect relationship between bad names and bad code. IME bad names lead to bad code, not usually the other way around. The reason is that by starting from good name choices, it’s much easier to have a well structured code. And not rarely, bad names lead to mangled up code that screams for a refactoring.
To each their own. But man imagine if you have a collection of stuff that has a large name, and then having to figure out a short name other than e when iterating. I hope you’re not iterating over chemical names 😬
Depends. If you’re using a good ol’ C-style for loop then nothing’s wrong with for(int i = 0; i < something;i++), but if you’re doing something like iterating over some collection it’s way clearer to do something like foranimalin animals: than it is to do forein animals:.
Especially if you’re doing something non-trivial for each element
Well in a vacuum yes sure, you’re right, but in practice there’s always some context. x and y could be referring to axes, where an addition makes little sense. However lhs and rhs make more sense if you’re overloading an operator
and that’s yet another way to end up with hard to read code.
Variables hold values that have meaning. Learn how to name things and you’ll write good code.
edit: someone just wrote an article along these lines. The only thing I’d change is the cause-effect relationship between bad names and bad code. IME bad names lead to bad code, not usually the other way around. The reason is that by starting from good name choices, it’s much easier to have a well structured code. And not rarely, bad names lead to mangled up code that screams for a refactoring.
This makes me want to write a function for you to add to numbers where the variables are leftumber and rightnumber, instead of x and y.
if “left” and “right” were relevant for addition, they would indeed be better names
Are you against using a single letter variable like e for element in iterating over things?
yes
To each their own. But man imagine if you have a collection of stuff that has a large name, and then having to figure out a short name other than e when iterating. I hope you’re not iterating over chemical names 😬
No need to be over-descriptive. Anything at all more specific than
ewill probably be a better nameIt’s not black and white. I mean, even
elis a lot better thane.Depends. If you’re using a good ol’ C-style for loop then nothing’s wrong with
for(int i = 0; i < something;i++), but if you’re doing something like iterating over some collection it’s way clearer to do something likefor animal in animals:than it is to dofor e in animals:. Especially if you’re doing something non-trivial for each elementImplementing add (and other math operations) in rust for your types has the type signature self and rhs (right hand side).
Lhs and rhs are much better than x and y
In what way? If you encountered a function that had x and y which just added them together, that’s not readable enough?
Well in a vacuum yes sure, you’re right, but in practice there’s always some context. x and y could be referring to axes, where an addition makes little sense. However lhs and rhs make more sense if you’re overloading an operator