4 ms·

I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers w

I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing the actual code. This is the point where most people come to hate Clean Code.

tarcon 3mo ago
You mean people come to hate code reviews. If you don't use those rules, you'll argue about something else in the code reviews. Likely something even more ambigous that wasn't explicitly written down for everyone as a baseline.
locknitpicker 3mo ago
[flagged]
- lionkor 3mo ago
  There are way better metrics of function complexity, like how many branching points, how many loops, or even just how many levels of indentation. TDD, OOP, Clean Code, etc are an attempt to solve very real problems. They are then applied as dogma to places where these problems are not evident. That's the issue. Of course these rules have their place, but always with a caveat and never applied over all possible places where they might fit. Very often, a better solution exists, as well.
- ryanbrunner 3mo ago
  Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. There is absolutely a place for PR reviews, and I don't think the person you were replying to was against that, just that PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities. I can think of many times arbitrary rules like linting or Clean Code-esque standards resulted in a "solution" of making my code less readable.
  - rbanffy 3mo ago
    > Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. It's very hard to make a function you need to scroll back and forth to understand readable. Break it into smaller ideas that are more easily reasoned about. We love to think we are too clever, but we are not and we always need to keep an eye on cognitive load - having epifanies when you finally understand how something works is a great feeling, but relying on epifanies coming to you when you are trying to figure out how something works because it's not working now, is a terrible practice.
    - ryanbrunner 3mo ago
      I think the rule that "functions should be small enough that they should be easily reasoned about" is a reasonable rule, and it makes sense to follow it 95% of the time. "Functions should be 5 lines or less" is a measure that approximates that rule, but isn't exactly the same thing - I hope you agree we could both come up with 4 line functions that are impossibly complex or 6 line functions that are easily reasoned about. I think with Clean Code (and a lot of these kinds of things - Design Patterns is a great old example of this), people can get too dogmatic about applying these sort of approximated rules, when it would make a lot more sense for someone else (i.e. not the code writer) to use their best judgement and just directly answer the question "is this function easy to reason about?" rather than using the approximate measure.
      - rbanffy 3mo ago
        > "Functions should be 5 lines or less" This can’t really be a serious guideline unless you are writing APL, in which 5 lines can already be daunting to grasp. This guidance depends on the language. For Python, once you get over 50 lines it starts to look like you don’t actually know what you are doing anymore.
        ryanbrunner 3mo ago
        Sorry, you're right - 20 lines or less is the recommendation in the actual text of Clean Code. I have seen people try to push that down to 5 in Ruby on Rails development (IIRC, the most popular linter at one time tried to enforce 5 lines) In any case, the point stands - there are 19 line functions that are too sense, and 21 line functions that are sensible.
- rbanffy 3mo ago
  > The problem with a long function is not if it has N or N+1 lines of code, it's that length code with many branching conditions is prone to be untestable and introduce non trivial bugs. Once you start to refactor, not only is it easier to parse but harder to break. This fact is known for decades now. A function with too many lines is, most likely, doing more than one thing. Functions should do one thing, be easy to test (with few or no external dependencies whenever possible), be deterministic (unless required not to be), and so on. Excessive mocking is another code smell I look for - it often betrays poorly designed functions that can't be easily tested.
  - fellowniusmonk 3mo ago
    I once saw a professional software engineer try to refactor the spaghetti code in a complex bioinfomactics project written in python. It was a complete failure. That branch was abandoned and development continued off the spaghetti. There is a reason bioinformatics has its own set of viz charts that only they use. That's my anecdote anyway, it led me to the conclusion that sometimes things are continuous spaghetti and other than some small organizational changes, attempts to exhaustively discretize the code are a fools errand. The biggest benefits most projects like that are likely to see are performance and debugging improvements accomplished by factoring out recursion. Mapping to terrain is always the real effort in my opinion.
    - rbanffy 3mo ago
      > It was a complete failure. That branch was abandoned and development continued off the spaghetti. It was considered too hard, most likely because the present state of the code already degenerated beyond recovery. It might be difficult, but it's never impossible. > Mapping to terrain is always the real effort in my opinion. Yes. The domain might be complex, and it might be possible that there are no simple ways to work within that domain. Irreducible complexity is, after all, a thing.
- kelseyfrog 3mo ago
  Clean code nitpickers mistake the map for the territory. The rules are the map, maintainability is the territory. The map is a model of the territory, but the territory always contains more detail, both zones of maintainability not covered by the rules and zones of unmaintainability covered by the rules. The rules are heuristics, and like all heuristics, they have false positives and false negatives. Being a mature developer means knowing the limits of tools including processes, style, and standards. When they nit to the rules and not to the goal, it doesn't contribute, it distracts.
- deleted 3mo ago
  [deleted]
- the__alchemist 3mo ago
  It sounds like we have opposite programming styles!
HeavyStorm 3mo ago
[flagged]
MrBuddyCasino 3mo ago
Well said. It is not without merit, but tends to attract the tedious killjoys and midwits. The bureaucrats who above all value process over outcome.
cavoirom 3mo ago
I learned Clean Code at the beginning of my career, but I don't actually get it. Recently I know about "testable code" from Justin Searls. I found the "testable code" concept is more useful because we can monitor the effectiveness of the concept and I can see the actual benefits in my projects.
tcfhgj 3mo ago
[flagged]
- tranceylc 3mo ago
  Even the author of clean code would fall under someone who can’t program
  - tcfhgj 3mo ago
    what? I am talking about knowing the idea of clean code, which doesn't include dogmatically limiting #locs in functions to an arbitrary number. So if someone hates clean code for someone doing that, it's just dumb.
wing-_-nuts 3mo ago
My personal benchmark for 'maybe this function is too long' is when it doesn't fit on the page.
- jeltz 3mo ago
  I don't think any such benchmark should exist. As long as the function only does one thing there is no upper limit. Artificially splitting a large function only reduces readsbility. What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. I personally write quite short functions but I have never understood why people take issue with large functions. Those are one of the easiest things to fix in a bad codebase. It is much harder to clean up after someone who used too small functions.
  - azertify 3mo ago
    There aren't usually many domains where a process can't be described as a series of steps. Deciding what those are called, and structuring data in such a way that it each of those steps works sensibly can be challenging, but that is the process of making code comprehensible. I can remember as a novice that I would write an entire program in a single, many-thousand line function, unable to see where the boundaries between functions should be. With experience and expertise in the domain, it becomes easier to see where those should be.
  - tcfhgj 3mo ago
    > What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? depends on what the function does, most likely the best decomposition into functions isn't simply splitting the function in to n sequential parts > I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. one thing usually consists of multiple other things imho length should correlate negatively with cyclomatic complexity - it's ok if you write 300 locs if all you do is fill a map with trivial entries
  - Someone 3mo ago
    > I don’t think any such benchmark should exist. wing-_-nuts says (emphasis added) “My personal benchmark for 'MAYBE this function is too long' is when it doesn't fit on the page.”. I think that’s a fine heuristic. Long functions can be fine, but longer functions tend to be less testable, so you should try to avoid them. On the other hand, it can take lots of thinking to properly decompose functionality, and that decomposition can easily change when requirements change, so spending that time may not be worth it.
giancarlostoro 3mo ago
The function size is one rule from Clean Code I disagree with, it's silly. I love helper methods, but use them to a reasonable standard. I'd argue, if you cannot see it all on a 1080p monitor, that it might be getting a bit too long. I read PEP-8 religiously before I learned about "Clean Code" and it helped me to have sane standards in general. Methods that are roughly under 100 lines of code are okay, better is to fit it all in your monitor, 1080p being probably the most common resolution that leaves you with roughly 50 to 60 lines of code. If you have to scroll, you might want to consider helper functions to simplify and shorten logic. Functions always being under 10 lines just means you've got functions everywhere, which can be mentally exhausting to follow logic, if you aim for like 40 lines tops you can write better "stories" with your code that are easier to follow and more expressive.
- wren6991 3mo ago
  I'm fine with a 1k-line function if you just have that many things to do in a row without taking a breath. Breaking it up into smaller functions feels neater when you write it, but when I read it I'm essentially just macro-expanding it in my brain into the original 1k linear version, and that has some cognitive overhead (especially when they end up misordered in the file, or split across different files). I also have to think about whether there are any other areas of the code that might be calling your helpers, and whether they might break if I change the helper. Seeing everything inlined makes it absolutely clear from local reading that modifying the code only affects the local functionality. I'm not saying go insane and copy/paste the same thing multiple times, just that 1k-line functions are sometimes the least of all evils. I liked what John Carmack had to say on this topic: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Another point from that post that I try to take to heart: if it can be a pure function, it should be a pure function (even in C). Bob Martin's style is the opposite.
  - nomel 3mo ago
    I've heard this called "lasagna code". I've definitely drifted towards longer code, if nothing in that function is used elsewhere. Some tasks really are just lists of things to do (especially in something like image processing), and I think that sometimes it doesn't make sense to put lists of lists in your list of things to do.
wasmperson 3mo ago
> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain bad. The reason people get more pissed off at Clean Code than they would at any other book that gives bad advice is the preachy and authoritative tone it uses. It frames people who don't do "Clean Code" as unprofessional and lazy, and this framing is very convincing to some people, as evidenced by some of the replies in this thread.
- recursivecaveat 3mo ago
  The tone really is genius marketing though. Like who wants to be a "dirty" coder? Reminds me of that quote about the etymology of dynamic programming: > it's impossible to use the word dynamic in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It's impossible. Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities.
- win311fwg 3mo ago
  > It frames people who don't do "Clean Code" as unprofessional and lazy Well, isn't that the whole reason for the profession? If you want to be professional and hardworking, why are you instructing a computer to do your work for you? If you aren't being unprofessional and lazy, you're in the wrong business.
  - cestith 3mo ago
    Larry Wall said the three virtues of a programmer are laziness, impatience, and hubris. He meant when properly applied, of course.
- antonymoose 3mo ago
  I would charitably say that it’s a function of a different time and place in programming. The way you write “Clean COBOL,” “Clean Java 6/J2EE,” and “Clean Rust” are all going to be very different. There is still good meat-on-the-bone in the book, and especially interesting if you’re working in a legacy system from that older time and place.
98codes 3mo ago
Adopting anything as blind dogma is Expert Beginner territory. See also: DB table normalization.
- ozim 3mo ago
  I basically spent 2 full years removing normalization from our two projects that was originally added because devs followed best practice. Those 2 years were to do the data migration and of course there were different priorities, if that would be priority we would do it in 1 month, but we liked to spread risk over time. Reason was of course performance issues and not really needed joins, where normalization didn't bring any benefit.
  - cestith 3mo ago
    In an ideal world the data at rest would be normalized and you’d have a view or a derived table or something when needed to make queries fast when necessary. If you ever find a job in an ideal world, hold on for dear life and please accept my CV for consideration.
- RaftPeople 3mo ago
  > See also: DB table normalization. Pragmatic approach: generally end up with an average of around 2.72 normalization across all tables.
BeetleB 3mo ago
> but harmful to late-stage developers who adopt it as dogma. Even Robert Martin, very often in his videos and blogs, espouses "engineering judgment" and is quite fine abandoning advice in his book when the situation calls for it. If performance is important and clean code is impacting it, he won't object to your breaking the rules. It's mostly with his TDD evangelism that he goes (a little) crazy.
- josephg 3mo ago
  I just think - in the book at least - he has really bad taste. The examples are full of “spooky action at a distance”. He writes the exact sort of class functions that make a lot of OO terrible to work with, where a function that should be pure has some weird hidden side effects. Code like that is really difficult to reason about and impossible to reuse safely. Somewhat ironic, given what he preaches in the rest of the book. I really like that he brings attention to the idea that code can be beautiful. But judging by his examples, he just seems to have no idea how to actually write beautiful software himself. I wish he went off and learned some functional programming. Haskell, Erlang, Clojure, F#. Something like that. Really go deep. If you want to know what really beautiful software looks like, that’s the place. Those communities know beauty.
  - BeetleB 3mo ago
    Yeah - I mostly watched his videos (the first N of them), and liked it. But later I saw examples from his book and they were terrible.
  - Scubabear68 3mo ago
    The ugly reality is consultants like Martin have little production coding experience. Martin has posts going back to the early 90s showing he had little understanding of how software teams work and deliver value. From what I have seen, his ideas were formed in a vacuum divorced from real coding. You can see it in the small amounts of open source he has released. The kind of guy who will always prefer 50 classes to 5. Who clutches his pearls at an if statement. I remember he was invited to give a talk at Bloomberg and the majority of us were simply disgusted that an obvious hack like him was lecturing a group of software engineers who had really been there and done that.
dirtbag__dad 3mo ago
I think you’ve missed the point of clean code if this is your gripe with it. Every time you over scope a function signature, because you want to handle that other case, you add mental tax to the next person. This accumulates, burns time, and now confuses agents, which is time and tokens ($). No one wants to work with a dogmatic individual but I’d rather a nit picker than a human or agent slop machine.
- bluefirebrand 3mo ago
  Okay, but Clean Code* would advocate you extract that function to its own class with a new abstraction and it would ultimately wind up way more complicated than the extra params in a function signature
  - tcfhgj 3mo ago
    No I wouldn't - keep it short & simple
    - bluefirebrand 3mo ago
      Nah, you gotta pay attention to what it does, not what it says Clean Code "says" keep it short and simple but following the advice that Bob lays out does not produce short and simple code
asdaqopqkq 3mo ago
i'd argue it is even more harmful for beginns, i remember we had to code a chess program and seeing students getting stuck on OOP stuff rather than actually solve the problems.
ericmcer 3mo ago
Sometimes it feels like the more someone has memorized all the little acronyms and jargon and principals around programming the worse they are as an engineer. I worked with a guy who would constantly drop niche jargon and quotes from famous engineers and then kind of smugly look at you. He could not write a function without proudly saying what principals it was following. He was a horrible programmer, ended up getting laid off.
0x20cowboy 3mo ago
Which would be fine if these people weren't the ones making / influencing the hiring decisions, paying them half a million dollars (even though they have done nothing) and people retweeted their “opinionated” takes on subjects they barely understand.

tarcon 3mo ago

You mean people come to hate code reviews. If you don't use those rules, you'll argue about something else in the code reviews. Likely something even more ambigous that wasn't explicitly written down for everyone as a baseline.

locknitpicker 3mo ago

[flagged]

lionkor 3mo ago
There are way better metrics of function complexity, like how many branching points, how many loops, or even just how many levels of indentation. TDD, OOP, Clean Code, etc are an attempt to solve very real problems. They are then applied as dogma to places where these problems are not evident. That's the issue. Of course these rules have their place, but always with a caveat and never applied over all possible places where they might fit. Very often, a better solution exists, as well.
ryanbrunner 3mo ago
Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. There is absolutely a place for PR reviews, and I don't think the person you were replying to was against that, just that PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities. I can think of many times arbitrary rules like linting or Clean Code-esque standards resulted in a "solution" of making my code less readable.
- rbanffy 3mo ago
  > Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. It's very hard to make a function you need to scroll back and forth to understand readable. Break it into smaller ideas that are more easily reasoned about. We love to think we are too clever, but we are not and we always need to keep an eye on cognitive load - having epifanies when you finally understand how something works is a great feeling, but relying on epifanies coming to you when you are trying to figure out how something works because it's not working now, is a terrible practice.
  - ryanbrunner 3mo ago
    I think the rule that "functions should be small enough that they should be easily reasoned about" is a reasonable rule, and it makes sense to follow it 95% of the time. "Functions should be 5 lines or less" is a measure that approximates that rule, but isn't exactly the same thing - I hope you agree we could both come up with 4 line functions that are impossibly complex or 6 line functions that are easily reasoned about. I think with Clean Code (and a lot of these kinds of things - Design Patterns is a great old example of this), people can get too dogmatic about applying these sort of approximated rules, when it would make a lot more sense for someone else (i.e. not the code writer) to use their best judgement and just directly answer the question "is this function easy to reason about?" rather than using the approximate measure.
    - rbanffy 3mo ago
      > "Functions should be 5 lines or less" This can’t really be a serious guideline unless you are writing APL, in which 5 lines can already be daunting to grasp. This guidance depends on the language. For Python, once you get over 50 lines it starts to look like you don’t actually know what you are doing anymore.
      - ryanbrunner 3mo ago
        Sorry, you're right - 20 lines or less is the recommendation in the actual text of Clean Code. I have seen people try to push that down to 5 in Ruby on Rails development (IIRC, the most popular linter at one time tried to enforce 5 lines) In any case, the point stands - there are 19 line functions that are too sense, and 21 line functions that are sensible.
rbanffy 3mo ago
> The problem with a long function is not if it has N or N+1 lines of code, it's that length code with many branching conditions is prone to be untestable and introduce non trivial bugs. Once you start to refactor, not only is it easier to parse but harder to break. This fact is known for decades now. A function with too many lines is, most likely, doing more than one thing. Functions should do one thing, be easy to test (with few or no external dependencies whenever possible), be deterministic (unless required not to be), and so on. Excessive mocking is another code smell I look for - it often betrays poorly designed functions that can't be easily tested.
- fellowniusmonk 3mo ago
  I once saw a professional software engineer try to refactor the spaghetti code in a complex bioinfomactics project written in python. It was a complete failure. That branch was abandoned and development continued off the spaghetti. There is a reason bioinformatics has its own set of viz charts that only they use. That's my anecdote anyway, it led me to the conclusion that sometimes things are continuous spaghetti and other than some small organizational changes, attempts to exhaustively discretize the code are a fools errand. The biggest benefits most projects like that are likely to see are performance and debugging improvements accomplished by factoring out recursion. Mapping to terrain is always the real effort in my opinion.
  - rbanffy 3mo ago
    > It was a complete failure. That branch was abandoned and development continued off the spaghetti. It was considered too hard, most likely because the present state of the code already degenerated beyond recovery. It might be difficult, but it's never impossible. > Mapping to terrain is always the real effort in my opinion. Yes. The domain might be complex, and it might be possible that there are no simple ways to work within that domain. Irreducible complexity is, after all, a thing.
kelseyfrog 3mo ago
Clean code nitpickers mistake the map for the territory. The rules are the map, maintainability is the territory. The map is a model of the territory, but the territory always contains more detail, both zones of maintainability not covered by the rules and zones of unmaintainability covered by the rules. The rules are heuristics, and like all heuristics, they have false positives and false negatives. Being a mature developer means knowing the limits of tools including processes, style, and standards. When they nit to the rules and not to the goal, it doesn't contribute, it distracts.
deleted 3mo ago
[deleted]
the__alchemist 3mo ago
It sounds like we have opposite programming styles!

HeavyStorm 3mo ago

[flagged]

MrBuddyCasino 3mo ago

Well said. It is not without merit, but tends to attract the tedious killjoys and midwits. The bureaucrats who above all value process over outcome.

cavoirom 3mo ago

I learned Clean Code at the beginning of my career, but I don't actually get it. Recently I know about "testable code" from Justin Searls. I found the "testable code" concept is more useful because we can monitor the effectiveness of the concept and I can see the actual benefits in my projects.

tcfhgj 3mo ago

[flagged]

tranceylc 3mo ago
Even the author of clean code would fall under someone who can’t program
- tcfhgj 3mo ago
  what? I am talking about knowing the idea of clean code, which doesn't include dogmatically limiting #locs in functions to an arbitrary number. So if someone hates clean code for someone doing that, it's just dumb.

wing-_-nuts 3mo ago

My personal benchmark for 'maybe this function is too long' is when it doesn't fit on the page.

jeltz 3mo ago
I don't think any such benchmark should exist. As long as the function only does one thing there is no upper limit. Artificially splitting a large function only reduces readsbility. What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. I personally write quite short functions but I have never understood why people take issue with large functions. Those are one of the easiest things to fix in a bad codebase. It is much harder to clean up after someone who used too small functions.
- azertify 3mo ago
  There aren't usually many domains where a process can't be described as a series of steps. Deciding what those are called, and structuring data in such a way that it each of those steps works sensibly can be challenging, but that is the process of making code comprehensible. I can remember as a novice that I would write an entire program in a single, many-thousand line function, unable to see where the boundaries between functions should be. With experience and expertise in the domain, it becomes easier to see where those should be.
- tcfhgj 3mo ago
  > What would you name the parts? do_stuff1(), do_stuff2(), do_stuff3()? depends on what the function does, most likely the best decomposition into functions isn't simply splitting the function in to n sequential parts > I have seen very clean codebases with a handful very long functions, but they were no issue she nice they only did one thing. one thing usually consists of multiple other things imho length should correlate negatively with cyclomatic complexity - it's ok if you write 300 locs if all you do is fill a map with trivial entries
- Someone 3mo ago
  > I don’t think any such benchmark should exist. wing-_-nuts says (emphasis added) “My personal benchmark for 'MAYBE this function is too long' is when it doesn't fit on the page.”. I think that’s a fine heuristic. Long functions can be fine, but longer functions tend to be less testable, so you should try to avoid them. On the other hand, it can take lots of thinking to properly decompose functionality, and that decomposition can easily change when requirements change, so spending that time may not be worth it.

giancarlostoro 3mo ago

The function size is one rule from Clean Code I disagree with, it's silly. I love helper methods, but use them to a reasonable standard. I'd argue, if you cannot see it all on a 1080p monitor, that it might be getting a bit too long. I read PEP-8 religiously before I learned about "Clean Code" and it helped me to have sane standards in general. Methods that are roughly under 100 lines of code are okay, better is to fit it all in your monitor, 1080p being probably the most common resolution that leaves you with roughly 50 to 60 lines of code. If you have to scroll, you might want to consider helper functions to simplify and shorten logic. Functions always being under 10 lines just means you've got functions everywhere, which can be mentally exhausting to follow logic, if you aim for like 40 lines tops you can write better "stories" with your code that are easier to follow and more expressive.

wren6991 3mo ago
I'm fine with a 1k-line function if you just have that many things to do in a row without taking a breath. Breaking it up into smaller functions feels neater when you write it, but when I read it I'm essentially just macro-expanding it in my brain into the original 1k linear version, and that has some cognitive overhead (especially when they end up misordered in the file, or split across different files). I also have to think about whether there are any other areas of the code that might be calling your helpers, and whether they might break if I change the helper. Seeing everything inlined makes it absolutely clear from local reading that modifying the code only affects the local functionality. I'm not saying go insane and copy/paste the same thing multiple times, just that 1k-line functions are sometimes the least of all evils. I liked what John Carmack had to say on this topic: http://number-none.com/blow/john_carmack_on_inlined_code.html http://number-none.com/blow/john_carmack_on_inlined_code.htm... Another point from that post that I try to take to heart: if it can be a pure function, it should be a pure function (even in C). Bob Martin's style is the opposite.
- nomel 3mo ago
  I've heard this called "lasagna code". I've definitely drifted towards longer code, if nothing in that function is used elsewhere. Some tasks really are just lists of things to do (especially in something like image processing), and I think that sometimes it doesn't make sense to put lists of lists in your list of things to do.

wasmperson 3mo ago

> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain bad. The reason people get more pissed off at Clean Code than they would at any other book that gives bad advice is the preachy and authoritative tone it uses. It frames people who don't do "Clean Code" as unprofessional and lazy, and this framing is very convincing to some people, as evidenced by some of the replies in this thread.

recursivecaveat 3mo ago
The tone really is genius marketing though. Like who wants to be a "dirty" coder? Reminds me of that quote about the etymology of dynamic programming: > it's impossible to use the word dynamic in a pejorative sense. Try thinking of some combination that will possibly give it a pejorative meaning. It's impossible. Thus, I thought dynamic programming was a good name. It was something not even a Congressman could object to. So I used it as an umbrella for my activities.
win311fwg 3mo ago
> It frames people who don't do "Clean Code" as unprofessional and lazy Well, isn't that the whole reason for the profession? If you want to be professional and hardworking, why are you instructing a computer to do your work for you? If you aren't being unprofessional and lazy, you're in the wrong business.
- cestith 3mo ago
  Larry Wall said the three virtues of a programmer are laziness, impatience, and hubris. He meant when properly applied, of course.
antonymoose 3mo ago
I would charitably say that it’s a function of a different time and place in programming. The way you write “Clean COBOL,” “Clean Java 6/J2EE,” and “Clean Rust” are all going to be very different. There is still good meat-on-the-bone in the book, and especially interesting if you’re working in a legacy system from that older time and place.

98codes 3mo ago

Adopting anything as blind dogma is Expert Beginner territory. See also: DB table normalization.

ozim 3mo ago
I basically spent 2 full years removing normalization from our two projects that was originally added because devs followed best practice. Those 2 years were to do the data migration and of course there were different priorities, if that would be priority we would do it in 1 month, but we liked to spread risk over time. Reason was of course performance issues and not really needed joins, where normalization didn't bring any benefit.
- cestith 3mo ago
  In an ideal world the data at rest would be normalized and you’d have a view or a derived table or something when needed to make queries fast when necessary. If you ever find a job in an ideal world, hold on for dear life and please accept my CV for consideration.
RaftPeople 3mo ago
> See also: DB table normalization. Pragmatic approach: generally end up with an average of around 2.72 normalization across all tables.

BeetleB 3mo ago

> but harmful to late-stage developers who adopt it as dogma. Even Robert Martin, very often in his videos and blogs, espouses "engineering judgment" and is quite fine abandoning advice in his book when the situation calls for it. If performance is important and clean code is impacting it, he won't object to your breaking the rules. It's mostly with his TDD evangelism that he goes (a little) crazy.

josephg 3mo ago
I just think - in the book at least - he has really bad taste. The examples are full of “spooky action at a distance”. He writes the exact sort of class functions that make a lot of OO terrible to work with, where a function that should be pure has some weird hidden side effects. Code like that is really difficult to reason about and impossible to reuse safely. Somewhat ironic, given what he preaches in the rest of the book. I really like that he brings attention to the idea that code can be beautiful. But judging by his examples, he just seems to have no idea how to actually write beautiful software himself. I wish he went off and learned some functional programming. Haskell, Erlang, Clojure, F#. Something like that. Really go deep. If you want to know what really beautiful software looks like, that’s the place. Those communities know beauty.
- BeetleB 3mo ago
  Yeah - I mostly watched his videos (the first N of them), and liked it. But later I saw examples from his book and they were terrible.
- Scubabear68 3mo ago
  The ugly reality is consultants like Martin have little production coding experience. Martin has posts going back to the early 90s showing he had little understanding of how software teams work and deliver value. From what I have seen, his ideas were formed in a vacuum divorced from real coding. You can see it in the small amounts of open source he has released. The kind of guy who will always prefer 50 classes to 5. Who clutches his pearls at an if statement. I remember he was invited to give a talk at Bloomberg and the majority of us were simply disgusted that an obvious hack like him was lecturing a group of software engineers who had really been there and done that.

dirtbag__dad 3mo ago

I think you’ve missed the point of clean code if this is your gripe with it. Every time you over scope a function signature, because you want to handle that other case, you add mental tax to the next person. This accumulates, burns time, and now confuses agents, which is time and tokens ($). No one wants to work with a dogmatic individual but I’d rather a nit picker than a human or agent slop machine.

bluefirebrand 3mo ago
Okay, but Clean Code* would advocate you extract that function to its own class with a new abstraction and it would ultimately wind up way more complicated than the extra params in a function signature
- tcfhgj 3mo ago
  No I wouldn't - keep it short & simple
  - bluefirebrand 3mo ago
    Nah, you gotta pay attention to what it does, not what it says Clean Code "says" keep it short and simple but following the advice that Bob lays out does not produce short and simple code

asdaqopqkq 3mo ago

i'd argue it is even more harmful for beginns, i remember we had to code a chess program and seeing students getting stuck on OOP stuff rather than actually solve the problems.

ericmcer 3mo ago

Sometimes it feels like the more someone has memorized all the little acronyms and jargon and principals around programming the worse they are as an engineer. I worked with a guy who would constantly drop niche jargon and quotes from famous engineers and then kind of smugly look at you. He could not write a function without proudly saying what principals it was following. He was a horrible programmer, ended up getting laid off.

0x20cowboy 3mo ago

Which would be fine if these people weren't the ones making / influencing the hiring decisions, paying them half a million dollars (even though they have done nothing) and people retweeted their “opinionated” takes on subjects they barely understand.