I clicked the link hoping for a critique of the ideas in SOLID and Clean Code, but what I got was an ironically long-winded critique of Bob Martin’s speaking style. Martin and I have our differences, but this article isn’t really useful. Martin has a brand and a style. A lot of people find it engaging and entertaining. If you don’t, that’s fine, there’s plenty of other ways to learn about the ideas that are more conc…
You are not alone in his style, but in what he actually says, all of which seems to me to be wrong.
Uncle Bob does a bad job talking about trade-offs, but there's still value in stuff like SOLID. The problems start when people blindly obey or ignore design principles. Saying SOLID makes bad code is as over-simplistic as saying SOLID makes good code.
The trouble with SOLID is that it's mainly an artifact of old languages and paradigms. 3 of the letters are almost irrelevant in modern code, or barely worth thinking about most of the time. So what's the value here? Single responsibility? That kind of thing is now so known that it doesn't really need talking about, like you don't really need to endlessly discuss the database normal forms like people did in the 00s.…
If single responsibility is so well known, when did I just this week see some code that violated that from a senior engineer? That code past review by a couple other programmers, without me looking at it and pointing out how horrible it was.
Re: Java classes called "SimpleFoo": that's usually because `Foo` is an abstract class or interface, and `SimpleFoo` is the version you actually use most of the time, unless you absolutely have to implement a `MyReallyComplexFoo` for some specific purpose.
I clicked the link hoping for a critique of the ideas in SOLID and Clean Code, but what I got was an ironically long-winded critique of Bob Martin’s speaking style. Martin and I have our differences, but this article isn’t really useful. Martin has a brand and a style. A lot of people find it engaging and entertaining. If you don’t, that’s fine, there’s plenty of other ways to learn about the ideas that are more conc…
Sorry if the title mislead you. To me criticizing SOLID and Clean Code directly is like beating a dead horse, so here I wanted to criticize the way they are presented because that's a big reason why it's successful.
To see really elegant and great code, I recommend looking in books. I have seen elegant code in: SICP, The Little Schemer, Software Design for Flexibility.
Problem is those are books. They are written by great programmers, but the problems are mostly toys - useful elegant examples, but the longest in SICP is still only a couple pages long. Sure it is cool they implemented SCHEME in a couple pages (you can tell how old the edition I have is), but if you wanted a real SCHEME implementation it would be much longer since you will want to spend a lot of time on optimization. If you want your SCHEME to be used it needs to have a standard library so that you don't have to write sort, trees, and all the other things we expect from a useful language. If you want this done in a reasonable amount of time you will need multiple programmers and in turn nobody will understand the full and so there will be some code that isnt' elegant.
Re: Java classes called "SimpleFoo": that's usually because `Foo` is an abstract class or interface, and `SimpleFoo` is the version you actually use most of the time, unless you absolutely have to implement a `MyReallyComplexFoo` for some specific purpose.
Ahh interesting. So it's Java convention/best practices being ported to other languages. Nothing wrong with using "simple" that if you explain it that way. I stand myself corrected.
I guess by now it's pretty settled down and unanimous that SOLID is an extremely bad way to organize your code, and that Clean isn't very good and has about the same odds of helping or harming you. But extending the complaint to all acronyms isn't helpful. ACID, OLAP, EBITDA, etc are perfectly good names with clear meanings that can be easily discovered.
You don't know many c# devs, then.
I have met exactly 1 developer that both followed the Microsoft recommended practices and didn't think they were bad.
While I agree the "Uncle Bob" cargo cult is IMO dumb, this really rubs me the wrong way: > You have the vendor pushed acronyms like: ACID, CAP, OLAP, OLTP. ACID and the CAP theorem in particular has _very_ serious consequences if you're doing anything that isn't a toy with a database, and if there was one thing worth beating into developers, it would be the consequences of those. With the big push on columnar stores…
Also, DRY, WET, YAGNI are useful ideas.
Yep. That's what they are. Useful ideas. The issue is treating them as rules or excuses for early/unnecesary abstractions.
While I agree the "Uncle Bob" cargo cult is IMO dumb, this really rubs me the wrong way: > You have the vendor pushed acronyms like: ACID, CAP, OLAP, OLTP. ACID and the CAP theorem in particular has _very_ serious consequences if you're doing anything that isn't a toy with a database, and if there was one thing worth beating into developers, it would be the consequences of those. With the big push on columnar stores…
Oh please don't confuse it with an aversion to formalism. It's quite the opposite. ACID, CAP and others were fantastic research when they came up. But now they are outdated and reductive of the real implications of running databases and distributed systems. That's why I mentioned PACELC being one of my favorite design principles in this matter: https://en.wikipedia.org/wiki/PACELC_design_principle My criticism of thi…
Humans like acronyms. You see them all over. If it seems like programmers like them more than others it is only because you are in that field and don't think about other fields. (did you know that Radar, and Scuba are acronyms? probably most readers do as soon as I pointed it out but if asked to come up with a non-programming acronym would have used others)
I read Clean Code when I was a beginner and found it revealing, but also annoying in parts, like the idea to 'do not use functions with more than 2 parameters.'