this post was submitted on 21 Apr 2024
131 points (95.8% liked)

Programming

17432 readers
221 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 1 year ago
MODERATORS
 

I don't entirely subscribe to the first paragraph – I've never worked at a place so dear to me that spurred me to spend time thinking about its architecture (beyond the usual rants). Other than that, spot on

you are viewing a single comment's thread
view the rest of the comments
[–] Dark_Arc@social.packetloss.gg 5 points 7 months ago (1 children)

I'll contest their is such a thing as good code. I don't think experienced devs always do the best job at passing on what works and what doesn't though. Universities certainly could do more software engineering/architecture.

My personal take is that SRP (the single responsibility principle) is the #1 thing to keep in mind. In my experience DRY (do not repeat yourself) often takes precedence over SRP -- IMO because DRY is easy to (mis-)understand -- and that ends up making some major messes when good/reasonable code is rewritten into some ultra-compact (typically) inheritance or template-based mess that's "fewer lines of code, so better."

I've never regretted using composition (and thus having a few extra lines and a little bit more boilerplate) over inheritance. I've similarly never regretted breaking down a function into smaller functions (even if it introduces more lines of code). I've also never regretted generalizing code that's actually general (e.g., a sum N elements function is always a sum N elements function).

The most important thing with all of these best practices though is "apply it if it makes sense." If you're writing some code and you've got a good reason to have a function that does multiple things ... just write the function, don't bend over backwards doing something really weird to "technically" abide by the best practice.

[–] magic_lobster_party@kbin.run 4 points 6 months ago* (last edited 6 months ago)

I've never regretted using composition (and thus having a few extra lines and a little bit more boilerplate) over inheritance.

I second this. It doesn’t necessarily eliminate bad code, but it certainly makes it more manageable.

Every time inheritance is used, it will almost certainly causes pain points that’s hard to revert. It leads to all these overly abstracted class hierarchies that give OOP a bad rep. And it can be easily avoided in almost all cases.

Just use interfaces if you really need polymorphism. Often you don’t even need polymorphism at all.