Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Clean" Code, Horrible Performance (2023)

computerenhance.com

Post reply on HN
Print view View original

121–130 of 192 posts

Re: "Clean" Code, Horrible Performance (2023)

#121

Post by josephg »

pseudony wrote: post #120
josephg wrote: post #109

Earlier quoted context omitted.

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 t…

You mean Clojure, and he did. He is very enthusiastic about it, vastly preferring it to Java. Fyi.

Fixed! And I'm glad to hear it. If his blog is anything to go by, it looks like he was messing around in clojure in about 2019, 12 years after he wrote Clean Code.

Maybe we'll see an updated version some day, with better examples. It would be valuable if only so people would stop trying to defend his old, bad advice.

Re: "Clean" Code, Horrible Performance (2023)

#122

Post by Jtsummers »

josephg wrote: post #121
pseudony wrote: post #120

Earlier quoted context omitted.

You mean Clojure, and he did. He is very enthusiastic about it, vastly preferring it to Java. Fyi.

Fixed! And I'm glad to hear it. If his blog is anything to go by, it looks like he was messing around in clojure in about 2019, 12 years after he wrote Clean Code. Maybe we'll see an updated version some day, with better examples. It would be valuable if only so people would stop trying to defend his old, bad advice.

It was updated and the second edition was published last year. I have not read it so have no idea what changed and what did not.

Re: "Clean" Code, Horrible Performance (2023)

#123

Post by pragmatic »

taybin wrote: post #19

Yes, a toy problem only needs a simple implementation. This is a straw man. And I don't even like Robert Martin's Clean Code, but the author is not addressing where this style actually provides benefits. When you're updating 23 if-statements because you had to add support for some new business workflow, you'll wish you had a conceptual entity that encapsulated the operations on the type of workflows so you just had t…

What?

Re: "Clean" Code, Horrible Performance (2023)

#124

Post by nomel »

wren6991 wrote: post #94
giancarlostoro wrote: post #62

Earlier quoted context omitted.

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 f…

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…

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.

Re: "Clean" Code, Horrible Performance (2023)

#125

Post by dirtbag__dad »

Aurornis wrote: post #12

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…

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.

Re: "Clean" Code, Horrible Performance (2023)

#126

Post by pragmatic »

flossly wrote: post #5

I'd say Clean Code is teaching many bad-practices. Too many to be recommended.

Yes. So all you need to do is look at the code samples.

Is the most non-sensical thing I've seen. So of course the junior dev parade thinks it's the gospel.

Had a terrible manger who would swear by this book but couldn't code his way out of a paper bag.

Re: "Clean" Code, Horrible Performance (2023)

#127

Post by pragmatic »

teddyh wrote: post #89

Please note that this criticism is from 2023, but the “Clean Code” book has a second edition from 2025, extensively revised to account for the many misconceptions which new programmers might have gotten from the old edition, such as interpreting rules too strictly, etc.

Are the examples any better?

What a muddled bunch of gibberish.

Re: "Clean" Code, Horrible Performance (2023)

#129

Post by flossly »

pixlmint wrote: post #78
flossly wrote: post #11

Earlier quoted context omitted.

at bast it makes to better at "Clean(TM) OOP code". programming in general is waaaaaay bigger than what the book covers.

you realize reading books isn't a zero-sum game right? I can still read more books, it didn't end with Clean Code

and hence i scope it's message to "clean OOP code"; simply to show that it's flawed message does not even pertain to code in general.

Re: "Clean" Code, Horrible Performance (2023)

#130

Post by asdaqopqkq »

Aurornis wrote: post #12

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…

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.
Post reply on HN