For some actual code and comparison of principles behind Clean Code see: https://github.com/johnousterhout/aposd-vs-clean-code
And at the end of that Bob says: > For my part I'll just say that I have given due consideration to the points you've made, and while I disagree with your conclusions above, I have integrated several of your better ideas, as well as this entire document, into the second edition of Clean Code.
Solid and Clean Code never felt solid or clean to me
41–50 of 82 posts
Re: Solid and Clean Code never felt solid or clean to me
#42Earlier quoted context omitted.
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)
Re: Solid and Clean Code never felt solid or clean to me
#43I 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…
Re: Solid and Clean Code never felt solid or clean to me
#44Re: Solid and Clean Code never felt solid or clean to me
#45I'm on 4G mobile, that stock photo of sheep is 19MB PNG file! Thanks.
Re: Solid and Clean Code never felt solid or clean to me
#46> To me people calling their code or software “Clean”, “Easy”, or “Simple” has always felt wrong. You aren’t entitled to declare your own creation to have some subjective trait you strived for when writing it.
Follows:
> The more objective you assume you are, the more easily manipulated you can be by subjectivity, be it your own subjectivity or others.
I'm happy to go on record stating the former is more forgivable than a lazy false truism or platitude.
Re: Solid and Clean Code never felt solid or clean to me
#47Re: Solid and Clean Code never felt solid or clean to me
#48Earlier quoted context omitted.
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.…
Single Responsibility was written about nearly 40 years after cohesion was grafted into software design from an actual architect's (like buildings and cities, absolutely not software o doctoral thesis. "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." Has humanity progressed so much that…
Re: Solid and Clean Code never felt solid or clean to me
#49What I dislike about the term "clean" code is that it dismiss objective criteria. "I did it like that because it's cleaner" is a non sense. A program must be maintenable, efficient, observable, testable, scalable, performant, readable, secured. Each criteria can be objectively measured in a kind of radar diagram and can be maximized as long as it does not sacrifice another criteria. Form follows function. Even "simpl…
This is the key that most people miss.
The second thing most people miss is most of the time efficient, scalable, and performant are good enough. Not always, there are no absolutes, but most of the time you can safely compromise those 3 without any problem that the real world will notice. In general maintainable has proven to be the hardest/most expensive, and so clean code is most important (don't confuse with Clean Code as a book or any set of rules puts it). Indeed, observable and testable are just different ways to express maintainable. (the first is you can understand what went wrong, and the second you can ensure your changes don't break something else).
Secure is the final thing I didn't mention. this is becoming more and more important. It may even become more important than maintainable in the future.
Re: Solid and Clean Code never felt solid or clean to me
#50I was given Clean Code as a junior developer... didn't think it was mind blowing, but I used the parts that made sense and left the parts that didn't... what you're supposed to do anytime you're exposed to other peoples opinions. And I never felt a need to follow it blindly. If your code got inappropriately criticized by your leads or managers for not being Clean or SOLID enough, or they forced you into following Clean Code like it was the bible, then be mad at those guys!