this post was submitted on 11 Oct 2023
61 points (94.2% liked)
Programming
17484 readers
175 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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