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

21–30 of 216 posts

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

#21

Post by KerrAvon »

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…

Yeah, but read the very top of that post for his updated thoughts. The problem with manually inlining large functions is that they make code impossible to follow or reason about, which over time means that they turn into spaghetti code because people get lazy about reusing pieces from random other places in the same function.

His later addendum is important not to omit, because this is really the key to more reliable code:

> The real enemy addressed by inlining is unexpected dependency and mutation of state, which functional programming solves more directly and completely. However, if you are going to make a lot of state changes, having them all happen inline does have advantages; you should be made constantly aware of the full horror of what you are doing. When it gets to be too much to take, figure out how to factor blocks out into pure functions (and don.t let them slide back into impurity!).

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

#22

Post by jacquesm »

Jensson wrote: post #18
jacquesm wrote: post #14

Earlier quoted context omitted.

> 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. Point of inlining is to make it explicit that it is an ad hoc implementation for that location, so you don't have to be afraid of adding more stuff in it just to solve a local problem.

Easily solved with a comment and that frees you up from using it in more than one place if you ever feel like it. Inlining is a very low level implementation detail, I think making that explicit is something that you only want to do if you are breaking out the function for clarity and to be able to name it when it only lives in a single location. A bit like an assembly macro.

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

#23

Post by Jensson »

jacquesm wrote: post #22
Jensson wrote: post #18

Earlier quoted context omitted.

> A compiler should do this for you. Point of inlining is to make it explicit that it is an ad hoc implementation for that location, so you don't have to be afraid of adding more stuff in it just to solve a local problem.

Easily solved with a comment and that frees you up from using it in more than one place if you ever feel like it. Inlining is a very low level implementation detail, I think making that explicit is something that you only want to do if you are breaking out the function for clarity and to be able to name it when it only lives in a single location. A bit like an assembly macro.

Not sure what a comment would solve. The point is that if you are making an ugly implementation for some reason, then inlining that is the right choice, breaking it out into a function that can only safely be called in that exact spot is by far the worst technical debt you can create. If you have a pile of shit then don't put it on a fan and spread it all over the room, isolate it so you know where it is and other parts can ignore it easily.

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

#24

Post by Jensson »

jacquesm wrote: post #19
Jensson wrote: post #13

Earlier quoted context omitted.

> and ideally don't cause unexpected side-effects etc., though when a function is 5-lines long, that's fairly easy to spot Not easy to spot side effects if the 5 line function calls 999 other 5 line functions, which you have to do if you replace 1 function with 1000 functions. When people start to arbitrarily break up tightly coupled implementations into tiny functions you will get a much worse mess than if they just…

That simply overdoing it. 50 line functions are fine, 100 line functions can be useful. 5000 line functions should be an exception and 5 line functions can be useful if you can still give them a clear name and they end up being either re-used or are internal. If you start exporting 100's of functions you may want to re-evaluate the way you are interfacing your modules.

The question wasn't "what is the best way to write code" but "is 1000 5 line functions preferable to 1 5000 line function". Of course the best way is somewhere in between, but that wasn't what we were discussing.

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

#25

Post by dathinab »

the thing with that book, and many similar books is that if you take the recommendation verbatim they often 1) only apply to one language 2) get outdated really fast.

What matters is understanding the "general concept/ideas" and apply them "as appropriate".

Most important over obsessing about specific rules is nearly never a good idea, but to some degree that is what is needed to write a book like that to illustrate the idea. And this is also where Clean Code fails, it's often too specific in exactly how to do certain things. But that is also what made it so successful because it makes it accessible.

Today Clean Code and some other such books are still a grate source to compare your experience/knowledge against in a critical way to find additional insights.

Through if you want a book which you can blindly follow or you don't have the experience to judge code style recommendations its probably best to keep the hands of it.

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

#27

Post by dang »

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)

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

#28

Post by userbinator »

wizofaus wrote: post #8
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…

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.

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

#30

Post by DanielVZ »

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 unnecessarily complex code in the name of the SOLID principles and others like DRY. Other times completely misunderstanding what the principles stand for and applying them in hand wavy ways.

This is a personal stretch, but even the marketing behind the principles is a bit of a red flag for me (Clean Code, SOLID, UNCLE BOB????). To me it sounds like someone made a career out of this.

I wish we had a better book to recommend to newcomers.

Post reply on HN