this post was submitted on 01 Jan 2026
12 points (92.9% liked)

Programming

24240 readers
544 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
top 9 comments
sorted by: hot top controversial new old
[–] squaresinger@lemmy.world 7 points 5 days ago

The one good principle. And I now I can see why: it was invented by people who knew their maths — type theory in this case. In lay terms it’s simple: anything you can observe about the base class, remains true of its derived classes. That way you can pretend instances of the derived classes are also instances of the base class, without any nasty surprise.

On the one hand, duh: that’s just subtyping. But on the other hand, very few type systems enforce it — Java and C++ do not. That makes it very easy to make a dumb mistake like overriding a stable sort() method, and make it not stable for the derived class.

Javas immutable lists are an example of that right in the standard library.

The super type List has mutability. When you call any of these methods in the immutable list, you get an exception.

So if you have an arbitrary List object, you have no idea whether calling any method that mutates the object will work or not.

And this is doubly bad with the linter demanding you use Stream.toList() (which returns an immutable list) instead of Stream.collect(Collectors.toList()) (which returns a mutable list).

Horrible, dumb design.

[–] onlinepersona@programming.dev 5 points 5 days ago (1 children)

Just like all "principles" they shouldn't be blindly applied. Simply forcing SOLID upon a codebase won't magically make it better. In fact, I've seen codebases that "strictly follow SOLID principles" being terrible to understand, debug, follow, and optimise.

There will always be blind and zealous followers who will vehemently "protect" a codebase (or anything really) from impure modifications. They are the worst to deal with.

[–] calliope@retrolemmy.com 2 points 4 days ago* (last edited 4 days ago) (2 children)

The author actually mentions this in the article and finds no irony in it.

Okay, so the “principle” is now a judgement call

No shit. That’s the entire idea of every coding “principle”. For decades now! That’s actually what makes experience important… maybe that’s what this author is missing.

Not to beat on [a] dead horse, but [the rambling] alone should have been enough to make any competent programmer sceptical of anything [this author] has to say about programming.

They don’t lack confidence though!

[–] squaresinger@lemmy.world 1 points 2 days ago (1 children)

A principle is something you follow blindly, something that doesn't need a judgement call, and these do exist. Stuff like "Don't use goto", "Structure your code well", "No compiler warnings" and so on.

Something like the Liskov substitution principle.

That's why modern guidelines and styleguides separate stuff into "must" and "should", and a principle is always a must.

[–] calliope@retrolemmy.com 1 points 2 days ago* (last edited 2 days ago) (1 children)

I think you could be assuming a different definition of “principles” than Bob Martin was when he wrote them.

They weren’t “principles” like “a basic law or assumption.” It’s the second definition, principles as “a standard of good behavior.” (Such as in Cambridge’s definition here).

That is, using the “should” and “must” phrasing, I’ve always felt the SOLID principles were obviously more “should” than must. Good behavior is “should” but not something you follow blindly.

[–] squaresinger@lemmy.world 2 points 2 days ago (1 children)

Not sure if SOLID was meant as "should". At least when I was at university it certainly was taught as "must" and a lot of coworkers of mine also treated it as "must".

But anyway, it's super old stuff. SOLID was created in 2000. That's a quarter century ago and a ton has changed since.

Even Clean Code will be 17 years old this year. It's time to revisit all that, and most of it is just not nearly as good as it looks.

[–] calliope@retrolemmy.com 2 points 2 days ago (1 children)

I’ve never met a decent, experienced developer who held these as incontrovertible truths. Lots of junior developers for sure. Maybe that’s a lot of what’s left.

Experience proves that holding a dogmatic view of “musts” for things like this is frequently an issue in itself. Maybe it’s time everyone tried to learn that lesson again.

[–] squaresinger@lemmy.world 2 points 2 days ago* (last edited 2 days ago)

I think simple "musts" can be helpful on an organizational level to synchronize work. Stuff like "must use one of the approved languages", "must use git", "must use a linter with a given preset", "must get rid of all compiler warnings". That kind of stuff just makes working together easier, but neither of them are dogmatic truths but just stuff to make organization and working together easier.

But I agree that dogmatic views for broader subjects are very often harmful but at the same time rarely bring a lot of benefit. I've worked at a project before where the former lead dev was a really bad and dogmatic developer who managed to get to this position through intimidation. He followed "Clean code" to excessive lengths, which meant that it was quite common that a simple 1 Story Point change required touching 40+ files. Hardly any method was longer than 5 lines, hardly any class had more than one method, everything was split up like crazy.

Imagine writing code, but instead of lines you use classes instead.

I have met quite a few long-term developers with senior titles and sometimes even lead dev or architect titles who follow dogmatic views to the extreme.

I agree that no decent developer would, but that's a bit of a circular definition (since being dogmatic precludes you from being decent).


And I totally wished universities would be better at explaining that design principles are decent guidlines if you don't have any other basis to make a decision, but that they are ultimately tools in a toolbox and a good developer needs to understand when to use them and when not to.

Too many people come out of university thinking that SOLID or Clean Code are the bible.

[–] onlinepersona@programming.dev 4 points 4 days ago

Yep, I enjoyed the article. Unfortunately, it won't convince zealots. Reason rarely does.