I read Uncle Bobs book on clean-code. Also listened to his talks.
Most of it is true. Although his particular example on how to clean up this Java-Class does not really make it better. I once read a rant about it, it was good.
The good thing is, that Uncle Bob knows that all the clean-code "rules" are open for discussion - he dares us to disagree.
(Btw. I got the German instead of the English version of the book - the typesetting is awful: no syntax-highlighting, and wrapped lines in the middle of variable names.)
Anyway, I took some "rules" from the book and I like to apply them whenever possible.
My favorite one, which seldom is taught to beginners is this one:
A method (function) that returns something does not alter state.
Thank you again for another thoughtful comment - I always enjoy your insights!
I also read Uncle Bob’s Clean Code years ago (in my case, the Polish edition 😄). And I completely agree: even if not every example lands perfectly, he raises a lot of valuable ideas and openly invites disagreement and discussion, which I appreciate.
The longer I work in this field, the less I rely on “gut feeling” for architectural decisions. These days I find myself reaching for proven design patterns much more intentionally - and almost every time I think: “Right, someone already solved this problem far better than I would have on intuition alone.”
That rule you mention - separating state-changing methods from return-value methods - is such a simple idea, yet it instantly clarifies so many design decisions. I wish more beginners were taught that early on.
Thanks again for contributing to this thread - your comments always add a lot of depth! 🙌
Yes, most of it is true. The problem with "clean code" is the subjective nature of the recommendations. It results in different (often conflicting) interpretations. But the worst thing is that even strict and correct following of all "clean code" rules does not eliminate subjective factors. Over time, codebase is just a bunch of scars of personal styles and approaches. Consequences are devastating - moths of onboarding, code silos, and constant mental overhead caused by incompatibility of the ways different devs see the problem and the solution. Not to even mention PR reviews, which often turn into personal fights and constant obstacles instead of code quality improvement tools.
The times when we could rely on subjective criteria and judgments are over; software engineering should be, well, engineering and use engineering approaches. Similar tasks implemented by different devs should look similar and should take similar time to implement. Code should be unified to the level, when subjective component is virtuall non-existent. This will make onboarding virtually instant, anyone can read/understand/modify anobody elses's code without any issues, PR reviews finally will be focused on the correctness of the solution of the business task instead of things like how methods are named or should it be split into two or not.
I completely agree that the subjective nature of “clean code” is one of its biggest weaknesses. Two developers can follow the same principles and still produce results that feel totally different. And yes, you’re absolutely right - PR reviews often drift into personal style debates instead of focusing on what matters: solving the actual business problem.
At the same time, I think there will always be some level of subjectivity in software, simply because humans write the code. Even with strong engineering standards, patterns, and conventions, we still bring different experiences, mental models, and ways of reasoning about problems.
I do love the idea of reducing that subjectivity as much as possible - unifying patterns, aligning approaches, making onboarding easier. That’s where solid engineering guidelines and architecture decisions really shine. But I also think there’s value in leaving a bit of space for individual reasoning, creativity, and flexibility. Otherwise we risk turning the codebase into something too rigid to evolve.
So for me the sweet spot is:
strong shared conventions + room for pragmatic judgment.
But I really appreciate your perspective - especially the part about focusing PRs on correctness rather than style. I wish more teams did that.
Proposed approach does not eliminate creativity. Quite the opposite: you don't spend time on minor irrelevant details and can apply creativity and problem solving skills at higher level.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I read Uncle Bobs book on clean-code. Also listened to his talks.
Most of it is true. Although his particular example on how to clean up this Java-Class does not really make it better. I once read a rant about it, it was good.
The good thing is, that Uncle Bob knows that all the clean-code "rules" are open for discussion - he dares us to disagree.
(Btw. I got the German instead of the English version of the book - the typesetting is awful: no syntax-highlighting, and wrapped lines in the middle of variable names.)
Anyway, I took some "rules" from the book and I like to apply them whenever possible.
My favorite one, which seldom is taught to beginners is this one:
This makes many design decisions much easier.
Thank you again for another thoughtful comment - I always enjoy your insights!
I also read Uncle Bob’s Clean Code years ago (in my case, the Polish edition 😄). And I completely agree: even if not every example lands perfectly, he raises a lot of valuable ideas and openly invites disagreement and discussion, which I appreciate.
The longer I work in this field, the less I rely on “gut feeling” for architectural decisions. These days I find myself reaching for proven design patterns much more intentionally - and almost every time I think: “Right, someone already solved this problem far better than I would have on intuition alone.”
That rule you mention - separating state-changing methods from return-value methods - is such a simple idea, yet it instantly clarifies so many design decisions. I wish more beginners were taught that early on.
Thanks again for contributing to this thread - your comments always add a lot of depth! 🙌
Yes, most of it is true. The problem with "clean code" is the subjective nature of the recommendations. It results in different (often conflicting) interpretations. But the worst thing is that even strict and correct following of all "clean code" rules does not eliminate subjective factors. Over time, codebase is just a bunch of scars of personal styles and approaches. Consequences are devastating - moths of onboarding, code silos, and constant mental overhead caused by incompatibility of the ways different devs see the problem and the solution. Not to even mention PR reviews, which often turn into personal fights and constant obstacles instead of code quality improvement tools.
The times when we could rely on subjective criteria and judgments are over; software engineering should be, well, engineering and use engineering approaches. Similar tasks implemented by different devs should look similar and should take similar time to implement. Code should be unified to the level, when subjective component is virtuall non-existent. This will make onboarding virtually instant, anyone can read/understand/modify anobody elses's code without any issues, PR reviews finally will be focused on the correctness of the solution of the business task instead of things like how methods are named or should it be split into two or not.
I completely agree that the subjective nature of “clean code” is one of its biggest weaknesses. Two developers can follow the same principles and still produce results that feel totally different. And yes, you’re absolutely right - PR reviews often drift into personal style debates instead of focusing on what matters: solving the actual business problem.
At the same time, I think there will always be some level of subjectivity in software, simply because humans write the code. Even with strong engineering standards, patterns, and conventions, we still bring different experiences, mental models, and ways of reasoning about problems.
I do love the idea of reducing that subjectivity as much as possible - unifying patterns, aligning approaches, making onboarding easier. That’s where solid engineering guidelines and architecture decisions really shine. But I also think there’s value in leaving a bit of space for individual reasoning, creativity, and flexibility. Otherwise we risk turning the codebase into something too rigid to evolve.
So for me the sweet spot is:
strong shared conventions + room for pragmatic judgment.
But I really appreciate your perspective - especially the part about focusing PRs on correctness rather than style. I wish more teams did that.
Proposed approach does not eliminate creativity. Quite the opposite: you don't spend time on minor irrelevant details and can apply creativity and problem solving skills at higher level.