this post was submitted on 05 Jan 2025
61 points (90.7% liked)
Programming
17810 readers
503 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 !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
To preface, I think it's best to focus on what the right approaches are. Not on what to avoid. And when you see a student making a mistake, showing them how a different approach is handier (if possible) is what I suggest you do.
Having something to point at doesn't help much
vertical separation
This one argues against organizing your code in a way that shares variables are in one place. There are arguments to be made either way, but normally you'd scope your variables in a way that the ones specific to a particular bit of code are not accessible from elsewhere.
null check
Suggest writing a custom class to do what most languages can solve with inheritance or even better: the ? syntax.
inconsistent names / styles
Yes, it can be annoying. No, clarity is more important than insisting on removing that extra underscore.
complicated Boolean expression
They're advocating the use of a function to replace an expression. Sometimes this works, but the task of a boolean expression is not always easily expressed in a couple words. And so you can end up with misleading function names. Instead, just put a comment in the code.
callback hell
Not even a code smell. It's an issue from back when languages like JavaScript didn't support promises yet, but callbacks were popular. Cose got hard to read with a little complexities.
inheritance rarely solves anything
You gotta know how to use it properly
At that point I would argue composition/traits are the way to go.
"This extends Draggable". That's great but now we can't extend "Button" to override the click handler.
Traits: You wanna have Health, and do Damage, but don't want to implement InventoryItem? No problem. You wanna be an Enemy and InventoryItem? Go for it. What's this function take? Anything that implements InventoryItem + Consumable
use an interface?
Yeah Interfaces would be the next best thing.
The only reason why traits are considered better is because in languages like rust it can enable static dispatch. Whereas interfaces in C#, Java, Typescript, (and C++ via abstract classes, not templates) are always dynamic dispatch.
Looking at the Rust docs, it looks like it's not much more than a difference in implementation under the hood.
It would be clunky, but in C# you could duct tape this: make a static abstract method in an interface that takes an object named 'self', then an extension method that extends the class and just casts then runs the function with Unsafe.As<TFrom, TTo>(ref obj), or an explicitly aligned struct with overlapping values.
I don't expect any such implementation anytime soon though :/
ps: Typescript can go take a hike, it's a superset for a language that was never designed for this