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

51–60 of 216 posts

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

#51

Post by userbinator »

albertopv wrote: post #34
userbinator wrote: post #5

A common theme not only in software but other industries: Beware of people selling you advice. They are the ones who will breed dogmatic illogical cargo-cults of people whose only rebuttal when questioned is some variant of "because someone who sold me this book that claims it'll make my code better said so", and that can't be a good thing in general. but we assume that Martin doesn't literally mean that every functi…

You can have 1000 5-lines functions in all languages, not only java. Typescript FE projects can be as hard as java ones to read. It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases.

It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases.

I don't think that's the reason. The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much, and as a result you end up with what's classically known as "enterprise" code. I've seen the work of "low skilled devs" in other languages like PHP, VB, etc. and that leans far on the under-abstraction side; you're far more likely to find lots of copy-pasting and kiloline-long functions (if they even bother to write more than one), yet that code tends to be easier to work with in my experience because it's largely linear and not nested.

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

#52

Post by moomoo11 »

Eh. I like that people who actually understand the principles behind Clean Code can share a common understanding of how we are going to put the legos together.

Don’t have to spend too much time bikeshedding. Experienced enough to have some foresight and pragmatic enough to know where to draw the line.

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

#53

Post by dietrichepp »

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 be correct and easy to understand. I think “correct and easy to understand” is a much more useful rubric than “clean”. Obviously it’s still subjective. Code that is easy to understand for you may be hard for me to understand. Likewise, code that is correct for your use cases may be incorrect for my use cases. But it’s much easier to come to an agreement about “correct and easy to understand”, or at least communicate issues with the code using that basis.

Like, “you shouldn’t use boolean flags as parameters, you should use enums” becomes “I can‘t understand the meaning of true/false at the call site, so let’s use an enum instead”. This gives us a very clear, articulable basis for how we talk about code quality.

Of course, “correct and easy to understand” is not the be-all and end-all for describing good code. It’s just a nice substitute for the horribly vague, terribly subjective “clean”.

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

#54

Post by rightbyte »

userbinator wrote: post #5

A common theme not only in software but other industries: Beware of people selling you advice. They are the ones who will breed dogmatic illogical cargo-cults of people whose only rebuttal when questioned is some variant of "because someone who sold me this book that claims it'll make my code better said so", and that can't be a good thing in general. but we assume that Martin doesn't literally mean that every functi…

Ye flat functions are way underrated. It is so hard to keep track of the call stack when reading code for me.

Deeply nested code is read only, unless the problem is nicely modelled as recursive in some way.

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

#55

Post by albertopv »

userbinator wrote: post #51
albertopv wrote: post #34

Earlier quoted context omitted.

You can have 1000 5-lines functions in all languages, not only java. Typescript FE projects can be as hard as java ones to read. It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases.

It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases. I don't think that's the reason. The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much, and as a result you end up with what's classically known as "enterprise" code. I've seen the work of "low skilled devs" in other languages lik…

After some years I recently had to work on a very old PHP project with linear and untested code. Full of bugs, unmanaged corner cases, unnecessary code duplication, magic numbers...we didn't even try to understand the business logic or reverse it.

I still think it's just low skilled devs vs professional ones. You can make similar mistakes with many, many languages, it seems to me that Java went out of fashion, considered old.

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

#56

Post by userbinator »

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…

The claim is not that the book is dogmatic, but that its worshippers (for lack of a better word) are. The infamous Design Patterns book, despite having a similar "disclaimer", has had a similar effect.

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

#57

Post by userbinator »

jacquesm wrote: post #14
ZephyrBlu wrote: post #11

I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. If the work is c…

> If a function is only called from a single place, consider inlining it. A compiler should do this for you. > If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. This makes no sense to me. > If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters…

A compiler should do this for you.

Unless it outputs source code, it can't.

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

#59

Post by Groxx »

Yeah. This fits with my reading of it as well. Periodic chunks of "yep, makes sense" scattered through a really disturbing miasma of questionable stuff and incredibly tightly bound methods sharing gigantic balls of state that must be called in an order, but with nothing that hints at or enforces that order. It adds up to a really horrific result pretty frequently.

I'm not sure how it got its status at the beginning, but I think it retains it through sheer scale - it's a gigantic book for what it actually contains. It batters you with poorly connected ideas over and over and over until you can't tell right from wrong, and in the end you're just agreeing with whatever because doing otherwise gets you nowhere and nothing but pain as you try to read more. It's like a cult brainwashing ritual.

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

#60

Post by bambax »

ZephyrBlu wrote: post #11

I like Carmack's approach to functions the best: "If a function is only called from a single place, consider inlining it. If a function is called from multiple places, see if it is possible to arrange for the work to be done in a single place, perhaps with flags, and inline that. If there are multiple versions of a function, consider making a single function with more, possibly defaulted, parameters. If the work is c…

> If a function is only called from a single place, consider inlining it.

The main keyword is consider. Sometimes it's a good idea, and sometimes (often) it isn't.

Post reply on HN