- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
cross-posted from: https://lemmy.bestiver.se/post/832973
You must log in or # to comment.
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
Listhas mutability. When you call any of these methods in the immutable list, you get an exception.So if you have an arbitrary
Listobject, 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 ofStream.collect(Collectors.toList())(which returns a mutable list).Horrible, dumb design.
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.
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!
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.
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.
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.
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.
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.
Yep, I enjoyed the article. Unfortunately, it won’t convince zealots. Reason rarely does.
