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

It's probably time to stop recommending Clean Code (2020)

qntm.org

Post reply on HN
Print view View original

151–160 of 216 posts

Re: It's probably time to stop recommending Clean Code (2020)

#151

Post by kaba0 »

jahewson wrote: post #101
ornornor wrote: post #86

Earlier quoted context omitted.

So… how do you deal with this on a personal level? How do you retain any shred of sanity or enjoyment from your work? I can’t stand self inflicted toil and the stress from constant firefighting which is invariably the result of these short term policies. It makes me want to quit programming altogether and work in something totally unrelated even though I love programming. Just not the way employers want it.

One option is to work for a company where an important part of the product they make is code itself, e.g. an SDK. Another is to switch to a programming language that tends to attract quality-minded people, e.g Rust, Go, Haskell.

One is very different from the others.

The one whose designer said “ They’re not capable of understanding a brilliant language“

Re: It's probably time to stop recommending Clean Code (2020)

#152

Post by ravagat »

admo1 wrote: post #89

Am I the only one who thinks it's a great book and that it should still be among the top books to be recommended ? Maybe not the first one but easily in the top 10. Each time I see the same discussion on HN about this book, I'm always wondering why I see so many people going in either direction : not following the advice of the book at all, or following it too religiously. For me, the philosophy of the books was alwa…

You're not alone, its a great book and one of the better ones to be recommended but shouldn't be the only one. Unfortunately a lot of folks do exactly that.

Re: It's probably time to stop recommending Clean Code (2020)

#153

Post by ravagat »

dang wrote: post #27

Related: It's probably time to stop recommending Clean Code - https://news.ycombinator.com/item?id=29203295 - Nov 2021 (88 comments) It's probably time to stop recommending Clean Code (2020) - https://news.ycombinator.com/item?id=27276706 - May 2021 (658 comments) It's probably time to stop recommending Clean Code - https://news.ycombinator.com/item?id=23671022 - June 2020 (8 comments)

Quite interesting that it's always been the same article

Re: It's probably time to stop recommending Clean Code (2020)

#154

Post by amptorn »

Jtsummers wrote: post #39
DanielVZ wrote: post #30

Clean Code was one of the first books I read as a History student trying to become a self taught developer. From my point of view, coming from the rigor of historiography, the book was inconsistent and dogmatic. Still I took it as a replacement to talking with an experienced engineer, because that’s how it felt and most of the principles were fine when not taken to the extreme. But now in my career I’ve seen awfully…

I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter: > Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and prof…

This is kind of like a recipe book opening with a disclaimer saying "Some of these recipes might make you ill."

Re: It's probably time to stop recommending Clean Code (2020)

#155

Post by SergeAx »

ebiester wrote: post #138
dietrichepp wrote: post #53

My experience is that I run into a lot of relatively junior programmers who are concerned about clean code. Is my code clean? How do I organize my code? How do I make it clean? Should we clean up this code? I almost never want to use the word “clean” when I’m talking about code. These days, when someone asks me to review code, and they start talking about “clean” code, I shift the discussion to two points—code should…

What is easy to understand code? What if you have three people in the same code base who write "easy to understand" code for them, but inconsistent with each other? Even if those three all understand each other while writing it, this will not continue as the team changes and people have to onboard. As such, it isn't sufficient to have a linting standard: great codebases should have a consistent mental model. "Clean"…

Code is a kind of language. It is entirely possible to tell if person speaks clearly, easy to understand, or not. You may even train an ML model on Wikipedia section "Simple English".

The same applies to code. It is not 100% deterministic metric, but it is relatively easy to argue and have a consensus upon.

Re: It's probably time to stop recommending Clean Code (2020)

#156

Post by UglyToad »

userbinator wrote: post #28
wizofaus wrote: post #8

Earlier quoted context omitted.

Have you worked with 5000 line functions? Just trying to set breakpoints in them at meaningful points is a nightmare. Give me 1000 5-line functions any day - providing of course they have sensible names (and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot; in a 5000-line function, fuhgeddaboudit. My personal guideline is "it should fit on a screen"…

Yes I have, and some even approaching 10kl. It's actually easier when you only have one "dimension" to worry about, and can simply scroll up and down instead of having to jump around between functions, or worse, files. That said, a lot of these huge functions were basically for implementing defined step-by-step processes, and comments delineated the sections as well as loop and condition ends.

I think I have realised after ruining a previous codebase with overeager abstraction. Most code should read like fiction, not a reference book.

That is they should read top to bottom with minimal jumping around and information hiding.

(Of course not in all cases, YMMV, etc)

Re: It's probably time to stop recommending Clean Code (2020)

#157

Post by Groxx »

amptorn wrote: post #154
Jtsummers wrote: post #39

Earlier quoted context omitted.

I'm still amused by claims that the book is dogmatic when these paragraphs are in the opening chapter: > Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and prof…

This is kind of like a recipe book opening with a disclaimer saying "Some of these recipes might make you ill."

Immediately followed by many, many pages recommending that you add asbestos for flavoring, or lead for color.

A disclaimer doesn't change whether something is done or not. And it's a rather small fig leaf compared to the rest of the book.

Re: It's probably time to stop recommending Clean Code (2020)

#159

Post by sshine »

SergeAx wrote: post #155
ebiester wrote: post #138

Earlier quoted context omitted.

What is easy to understand code? What if you have three people in the same code base who write "easy to understand" code for them, but inconsistent with each other? Even if those three all understand each other while writing it, this will not continue as the team changes and people have to onboard. As such, it isn't sufficient to have a linting standard: great codebases should have a consistent mental model. "Clean"…

Code is a kind of language. It is entirely possible to tell if person speaks clearly, easy to understand, or not. You may even train an ML model on Wikipedia section "Simple English". The same applies to code. It is not 100% deterministic metric, but it is relatively easy to argue and have a consensus upon.

> it is relatively easy to argue and have a consensus upon

If you’re a reasonable person, yes. But when you’re not, all kinds of crazy patterns evolve.

E.g. a boss saying “I’m perfectly ok with functions that take more than 100 arguments.” (Compiler does not even support this.) and code being copy-pasted dozens of times being perfectly readable, but is a sink-hole when you refactor.

Clean Code (Martin’s book, and the movement in general) is my weapon when stubborn colleagues will not listen to reason. Sometimes they will listen to authority.

Re: It's probably time to stop recommending Clean Code (2020)

#160

Post by kcartlidge »

dietrichepp wrote: post #85
cush wrote: post #77

Earlier quoted context omitted.

It can definitely be confusing to hear "clean" when communicating in a professional setting. That said, in the book he covers correctness and understandability in nearly every paragraph. It's all the book is about really. It's called "clean" because it's concise and a catchy book title.

If you say the book “covers correctness and understandability in nearly every paragraph” then I’m convinced we must be talking about different books. For example, the book presents a rule for class names: > Classes and objects should have noun or noun phrase names like Customer, WikiPage, Account, and AddressParser. Avoid words like Manager, Processor, Data, or Info in the name of a class. A class name should not be…

> and if you like Strunk & White, then we disagree on at least two books

I'd be happy to shred Clean Code, but keep your hands off my Strunk and White!

Post reply on HN