7 ms·

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-comp

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex and objectively worse in hope it would be easier to extend later. Unfortunately we often dont know how the code will change, and in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears. IMHO optimizing for simplicity and readability has served me the best. Instead of avoiding the changes in code, it is better to write code so obvious that anyone can safely and easily change it when really needed. And finally, performance of the program vs performance of the developer is a false dichotomy. So many times I've seen a more readable, simpler code turned out to be more efficient as well. You often can have both.

Apocryphon 4y ago
Clean Code led to the development of the VIPER framework, which is a crime it must answer for.
- fulafel 4y ago
  I thought about https://github.com/viper-framework/viper https://github.com/viper-framework/viper first, but I guess you mean https://github.com/topics/viper-architecture https://github.com/topics/viper-architecture
- FlyingSnake 4y ago
  True. VIPER was the craziest thing I had to deal with when I developed iOS.
robalni 4y ago
I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?" Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated. That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.
- foo42 4y ago
  that last paragraph is an excellent description of the problem!
  - jackblemming 4y ago
    Strong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.
    - namaria 4y ago
      Hm... Ad hominem, truism, truism, ad hominem. And not even disagreeing with the conclusion in the end...
      - deleted 4y ago
        [deleted]
      - kubanczyk 4y ago
        I'd say false dilemma fallacy.
    - tpoacher 4y ago
      so ... sounds like you agree?
      - Ygg2 4y ago
        What is the alternative? Bad code? It's exactly same as arguing you should not educate your workers. Cause they might leave. So you get only the least knowledgeable ones.
  - lucumo 4y ago
    It's really not. Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way". So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a change.
userbinator 4y ago
So many times I've seen a more readable, simpler code turned out to be more efficient as well. In other words, if it's easy for the CPU to read, it's probably going to be easy for a human too. They both stumble a little on indirection and jumping around. The other advantage of simple (macro-level, and not "one line functions" micro-level simplicity) code is that it also tends to have fewer bugs, and what bugs do appear, are also easier to find and fix.
- jenadine 4y ago
  I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it can even be counter productive to hide details if these details are simpler than the abstraction itself. In summary, it's all about trade-offs and not over-doing it.
  - dsego 4y ago
    > Many abstraction makes it easier to read for human. Many abstractions are also conventions, just look at the js/react world. There is redux stores, mobx stores, hooks, class-based components, signals. All different abstractions with various performance and readability concerns. Someone used to one of them would say the others are not readable or maintainable. So maybe we can choose the more performant abstractions and teach them, so it becomes institutional knowledge.
  - badpun 4y ago
    > Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. CPU likes if/else and loops just as much as it like its gotos. If/else and loops are just conditional jump (with a comparison done before the jump), and gotos are uncoditional jumps. Both are very much machine code constructs, that's why they're in C (which is basically a syntactic sugar over assembly). Function calls are slightly more involved, but basically also very, very low level.
wirrbel 4y ago
Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" than "systems programming" for example (probably a bit tricky to actually define what the difference is between these too).
- readlikeasloth 4y ago
  This begs the question: what do you recommend instead?
  - avereveard 4y ago
    Code complete, Steve McConnell
  - markeibes 4y ago
    Programming practice
  - CraigJPerry 4y ago
    Not the OP but HTDPv2 is a solid recommendation here
    - asddubs 4y ago
      I don't understand why you would acronym your book recommendation. Anyone this would be a useful recommendation to would not know about it already, and hence not understand the acronym. For those wondering, "How to Design Programs"
      - CraigJPerry 4y ago
        Yeah fair comment. I guess i’ve fallen into that familiarity trap.
fulafel 4y ago
Interesting that he now prefers Clojure, where rules like "function names should be verbs" take a 180 and become don'ts.
oweiler 4y ago
Not only is it debatable, you never see any type of evidence. And how would you measure it?
goto11 4y ago
> I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. To be fair, this can be said about any technique. Lots of bad code results from people taking a reasonable principle and applying it religiously rather than judiciously.
- Ygg2 4y ago
  On the other side of taking Muratori advice too far, is the story of Mel. Or to be more precise the guy that comes after Mel. You have a ball of highly optimized mud, that quantum collapses if you glance at it too harshly, and we need it to be USB compatible. By Tuesday. Good luck!
tpoacher 4y ago
Clean code is defined as code that improves programmer efficiency and program readability, eschews premature optimisation by optimising for simplicity, makes code less complex and objectively better by optimising for readability, allowing virtually anyone to safely and easily change it when really needed. So you're actually a clean code proponent. As is usually the case with such debates, it is a debate of differing definitions masquerading as a debate of differing arguments.
- pkolaczk 4y ago
  Ok. Fair enough. I just find that what Uncle Bob calls clean code is often not clean code for me. E.g. preferring inheritance over switch is less readable. Flexibility/extensibility and readability are different things.
  - goto11 4y ago
    > E.g. preferring inheritance over switch is less readable. Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex. Of course there are cases where a switch is the right choice.
    - pkolaczk 4y ago
      Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.
      - goto11 4y ago
        So you are saying context doesn't matter, switch is always better?
dsego 4y ago
I've seen examples of FizzBuzz Enterprise in practice, eg a small algorithmic challenge that reads in some data and finds a value was split into several files, one class to read the data, one class to run the algorithm, one file to print out the results, etc etc. What was supposed to be one function with less than 50 lines turned into a multi-class multi-file monstrosity. The Java coder doing it couldn't imagine doing it any other way.
- ketzu 4y ago
  > a small algorithmic challenge For me that depends on the context: * A challenge for an interview? No wonder people try to insert structure as if it were a bigger project. * A challenge for a contest? Probably not a good solultion for most point systems. * A challenge for fun on hackerrank or LC? Whatever you feel comfortable with works. For structuring a larger system, separating data ingestion, data output and algorithm to work on the data, seems like a fairly entry level separation.
SPBS 4y ago
Thanks, this comment accurately captures my discomfort when reading the parts where Uncle Bob was talking. He consistently portrays Clean Code as a programmer friendliness vs processor speed tradeoff, while my impression of Clean Code has never been that it’s slow and programmer friendly, but full of overengineered design patterns that are horrible to read.“Premature optimisation in code flexibility” is a really succinct way of putting it.
- whstl 4y ago
  I personally find it full of rules that make sense in isolation and can make your code look pretty when you're a solo developer, but are actively making it more difficult to make the program understandable and flexible in the long way.
osigurdson 4y ago
I think we would be far better off in analyzing codebases that are considered well done and then try to reverse engineer some good practices out of these. Uncle Bob et all are just riffing on tiny sample projects that they work on in between speaking engagements. I’d trust the opinions of these types of people a lot more if they actually had achieved anything other than writing books and talking.
- lll-o-lll 4y ago
  Your words are harsh, but they are true. Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour. Money, damned filthy lucre, is of course the reason behind this. I don’t blame the players, but I do wish there was some way to inoculate the herd. Perhaps we need a proper religious tradition. Robes would at least make it fun.
  - osigurdson 4y ago
    >> Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour This is a great comment. Quotable even.
  - userbinator 4y ago
    Snake-oil salesmen have always existed in one form or another. OOP was pushed very strongly in the 90s, for example, and people promising to create massive increases in productivity by providing consulting services for "OOP-ifying" code probably made plenty of $$$ off that fad.
gofreddygo 4y ago
I think of this as a cross spectrum (terrible, good enough, well done, overdone) I've seen less production code and more discussions on code that focusses on opposite ends. terrible readability and maintainability with extreme performance. v/s. terrible performance with overdone "design" abstractions. OTOH, I've seen lot of production code that has good enough design, with well done perf and vice verse. Not much talk about that stuff.
xnx 4y ago
Like "Reduce. Reuse. Recycle." The logic behind "Make It Work. Make It Right. Make It Fast." is very deliberate.
z3t4 4y ago
I want to add reusability and removability. If I for example write some code that connects to a SMTP server to send an e-mail, I probably will re-use it in other places, even in other programs, so the code can't depend on global functions. The code should be independent. Then it also becomes removable and replaceable.
Gibbon1 4y ago
> Clean Code is mostly a premature optimization in code flexibility > in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears. Tying these two together. Clean Code doesn't distinguish between framework code and business logic code. Or more you should write the latter like the former. The problem is writing framework code is hard to do well. It needs to be well thought out, bullet proof, and importantly well documented. That takes a lot of time and effort and running the code under a number of different use cases. One is better off writing business logic as straight forward and goal directed as possible.
- whstl 4y ago
  That's interesting, this is the first time I've heard this critique, and I totally agree. The coding culture around Clean Code seems to put a lot of effort into "building frameworks on top of frameworks" without really admitting it, and the "framework-y bits" are intertwined with business logic, like exposed piping in a building. But business logic should look more like Golang instead.
Spivak 4y ago
This is pretty much my soapbox about DRY. Code is like clay, once it dries it’s not malleable anymore. Components that copy/paste but in doing so are self-contained can be fearlessly changed. And above a certain size dry works against you because when making changes to component A that requires a slight modification of the behavior or component Q deep in the call stack is so painful because the blast radius is huge. Dry codebases end up slowly accumulating more and more effectively read-only code that makes implementing non-trivial changes require increasing amounts of cleverness until development slows. I think the more general principle is more to do with code directionality and framework vs library but the motivation to franken-framework your code always seems to be dry.
- darepublic 4y ago
  Having worked with very non dry code where each instance has slight variations but none of the commonalities are captured.. I have to say it can cause a lot of bugs and a lot of headache to maintain.

Apocryphon 4y ago

Clean Code led to the development of the VIPER framework, which is a crime it must answer for.

fulafel 4y ago
I thought about https://github.com/viper-framework/viper https://github.com/viper-framework/viper first, but I guess you mean https://github.com/topics/viper-architecture https://github.com/topics/viper-architecture
FlyingSnake 4y ago
True. VIPER was the craziest thing I had to deal with when I developed iOS.

robalni 4y ago

I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?" Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated. That's the danger; good code is easy to change so it will easily get rewritten until it's not easy to change anymore.

foo42 4y ago
that last paragraph is an excellent description of the problem!
- jackblemming 4y ago
  Strong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.
  - namaria 4y ago
    Hm... Ad hominem, truism, truism, ad hominem. And not even disagreeing with the conclusion in the end...
    - deleted 4y ago
      [deleted]
    - kubanczyk 4y ago
      I'd say false dilemma fallacy.
  - tpoacher 4y ago
    so ... sounds like you agree?
    - Ygg2 4y ago
      What is the alternative? Bad code? It's exactly same as arguing you should not educate your workers. Cause they might leave. So you get only the least knowledgeable ones.
- lucumo 4y ago
  It's really not. Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way". So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a change.

userbinator 4y ago

So many times I've seen a more readable, simpler code turned out to be more efficient as well. In other words, if it's easy for the CPU to read, it's probably going to be easy for a human too. They both stumble a little on indirection and jumping around. The other advantage of simple (macro-level, and not "one line functions" micro-level simplicity) code is that it also tends to have fewer bugs, and what bugs do appear, are also easier to find and fix.

jenadine 4y ago
I disagree. Many abstraction makes it easier to read for human. Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. Now abstraction also have a cost that needs to be kept under control. (Some have zero costs, some have compile-time costs, some have different level of run-time costs) And of course, not every abstraction is a good one: Sometimes it can even be counter productive to hide details if these details are simpler than the abstraction itself. In summary, it's all about trade-offs and not over-doing it.
- dsego 4y ago
  > Many abstraction makes it easier to read for human. Many abstractions are also conventions, just look at the js/react world. There is redux stores, mobx stores, hooks, class-based components, signals. All different abstractions with various performance and readability concerns. Someone used to one of them would say the others are not readable or maintainable. So maybe we can choose the more performant abstractions and teach them, so it becomes institutional knowledge.
- badpun 4y ago
  > Example, the first abstraction is to use functions, if/else, and loops instead of plain goto everywhere like the CPU like. CPU likes if/else and loops just as much as it like its gotos. If/else and loops are just conditional jump (with a comparison done before the jump), and gotos are uncoditional jumps. Both are very much machine code constructs, that's why they're in C (which is basically a syntactic sugar over assembly). Function calls are slightly more involved, but basically also very, very low level.

wirrbel 4y ago

Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" than "systems programming" for example (probably a bit tricky to actually define what the difference is between these too).

readlikeasloth 4y ago
This begs the question: what do you recommend instead?
- avereveard 4y ago
  Code complete, Steve McConnell
- markeibes 4y ago
  Programming practice
- CraigJPerry 4y ago
  Not the OP but HTDPv2 is a solid recommendation here
  - asddubs 4y ago
    I don't understand why you would acronym your book recommendation. Anyone this would be a useful recommendation to would not know about it already, and hence not understand the acronym. For those wondering, "How to Design Programs"
    - CraigJPerry 4y ago
      Yeah fair comment. I guess i’ve fallen into that familiarity trap.

fulafel 4y ago

Interesting that he now prefers Clojure, where rules like "function names should be verbs" take a 180 and become don'ts.

oweiler 4y ago

Not only is it debatable, you never see any type of evidence. And how would you measure it?

goto11 4y ago

> I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. To be fair, this can be said about any technique. Lots of bad code results from people taking a reasonable principle and applying it religiously rather than judiciously.

Ygg2 4y ago
On the other side of taking Muratori advice too far, is the story of Mel. Or to be more precise the guy that comes after Mel. You have a ball of highly optimized mud, that quantum collapses if you glance at it too harshly, and we need it to be USB compatible. By Tuesday. Good luck!

tpoacher 4y ago

Clean code is defined as code that improves programmer efficiency and program readability, eschews premature optimisation by optimising for simplicity, makes code less complex and objectively better by optimising for readability, allowing virtually anyone to safely and easily change it when really needed. So you're actually a clean code proponent. As is usually the case with such debates, it is a debate of differing definitions masquerading as a debate of differing arguments.

pkolaczk 4y ago
Ok. Fair enough. I just find that what Uncle Bob calls clean code is often not clean code for me. E.g. preferring inheritance over switch is less readable. Flexibility/extensibility and readability are different things.
- goto11 4y ago
  > E.g. preferring inheritance over switch is less readable. Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex. Of course there are cases where a switch is the right choice.
  - pkolaczk 4y ago
    Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.
    - goto11 4y ago
      So you are saying context doesn't matter, switch is always better?

dsego 4y ago

I've seen examples of FizzBuzz Enterprise in practice, eg a small algorithmic challenge that reads in some data and finds a value was split into several files, one class to read the data, one class to run the algorithm, one file to print out the results, etc etc. What was supposed to be one function with less than 50 lines turned into a multi-class multi-file monstrosity. The Java coder doing it couldn't imagine doing it any other way.

ketzu 4y ago
> a small algorithmic challenge For me that depends on the context: * A challenge for an interview? No wonder people try to insert structure as if it were a bigger project. * A challenge for a contest? Probably not a good solultion for most point systems. * A challenge for fun on hackerrank or LC? Whatever you feel comfortable with works. For structuring a larger system, separating data ingestion, data output and algorithm to work on the data, seems like a fairly entry level separation.

SPBS 4y ago

Thanks, this comment accurately captures my discomfort when reading the parts where Uncle Bob was talking. He consistently portrays Clean Code as a programmer friendliness vs processor speed tradeoff, while my impression of Clean Code has never been that it’s slow and programmer friendly, but full of overengineered design patterns that are horrible to read.“Premature optimisation in code flexibility” is a really succinct way of putting it.

whstl 4y ago
I personally find it full of rules that make sense in isolation and can make your code look pretty when you're a solo developer, but are actively making it more difficult to make the program understandable and flexible in the long way.

osigurdson 4y ago

I think we would be far better off in analyzing codebases that are considered well done and then try to reverse engineer some good practices out of these. Uncle Bob et all are just riffing on tiny sample projects that they work on in between speaking engagements. I’d trust the opinions of these types of people a lot more if they actually had achieved anything other than writing books and talking.

lll-o-lll 4y ago
Your words are harsh, but they are true. Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour. Money, damned filthy lucre, is of course the reason behind this. I don’t blame the players, but I do wish there was some way to inoculate the herd. Perhaps we need a proper religious tradition. Robes would at least make it fun.
- osigurdson 4y ago
  >> Our industry has been a train wreck of mediocre ideas capturing mindshare and spread with religious fervour This is a great comment. Quotable even.
- userbinator 4y ago
  Snake-oil salesmen have always existed in one form or another. OOP was pushed very strongly in the 90s, for example, and people promising to create massive increases in productivity by providing consulting services for "OOP-ifying" code probably made plenty of $$$ off that fad.

gofreddygo 4y ago

I think of this as a cross spectrum (terrible, good enough, well done, overdone) I've seen less production code and more discussions on code that focusses on opposite ends. terrible readability and maintainability with extreme performance. v/s. terrible performance with overdone "design" abstractions. OTOH, I've seen lot of production code that has good enough design, with well done perf and vice verse. Not much talk about that stuff.

xnx 4y ago

Like "Reduce. Reuse. Recycle." The logic behind "Make It Work. Make It Right. Make It Fast." is very deliberate.

z3t4 4y ago

I want to add reusability and removability. If I for example write some code that connects to a SMTP server to send an e-mail, I probably will re-use it in other places, even in other programs, so the code can't depend on global functions. The code should be independent. Then it also becomes removable and replaceable.

Gibbon1 4y ago

> Clean Code is mostly a premature optimization in code flexibility > in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears. Tying these two together. Clean Code doesn't distinguish between framework code and business logic code. Or more you should write the latter like the former. The problem is writing framework code is hard to do well. It needs to be well thought out, bullet proof, and importantly well documented. That takes a lot of time and effort and running the code under a number of different use cases. One is better off writing business logic as straight forward and goal directed as possible.

whstl 4y ago
That's interesting, this is the first time I've heard this critique, and I totally agree. The coding culture around Clean Code seems to put a lot of effort into "building frameworks on top of frameworks" without really admitting it, and the "framework-y bits" are intertwined with business logic, like exposed piping in a building. But business logic should look more like Golang instead.

Spivak 4y ago

This is pretty much my soapbox about DRY. Code is like clay, once it dries it’s not malleable anymore. Components that copy/paste but in doing so are self-contained can be fearlessly changed. And above a certain size dry works against you because when making changes to component A that requires a slight modification of the behavior or component Q deep in the call stack is so painful because the blast radius is huge. Dry codebases end up slowly accumulating more and more effectively read-only code that makes implementing non-trivial changes require increasing amounts of cleverness until development slows. I think the more general principle is more to do with code directionality and framework vs library but the motivation to franken-framework your code always seems to be dry.

darepublic 4y ago
Having worked with very non dry code where each instance has slight variations but none of the commonalities are captured.. I have to say it can cause a lot of bugs and a lot of headache to maintain.