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

41–50 of 216 posts

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

#41

Post by c3534l »

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…

This feels like an alternative way of thinking about DRY. Make the running progra@ not have to repeat itself.

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

#42

Post by andirk »

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)

It's probably time to stop recommending "It's probably time to stop recommending Clean Code"

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

#43

Post by albertopv »

If OP expects a book, every coding book, will give advices to be followed literally, that's a problem. After 14y I know there's no recipe valid for everyone and every scenario and that's what I always says to new junior devs I have to train: it always depends. Are you prototyping? Are you developing critical infrastructure code, or a website? Restricted resources industrial appliance code?

I read that book when I was young, I followed some advices, some I didn't, then I made mine ideas.

Of course reading others books is also very helpful to contextualise Clean Code.

What I really, really recommend is NOT to read The Clean Coder book by same Rob Martin, it's one of the few I have been unable to even finish, it has been unbearable to me.

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

#44

Post by andirk »

Haven't read but it's definitely time to start demanding people write clean code. My house often gets messy, and so does my code. And then I clean my house and refactor my code. I try to steer away from refactoring for the sake of making my code look sexy, which it does, but putting time on the calendar for an almost guaranteed need to shuffle things around when you get a chance feels good and makes your future self happier.

A lot of people have no idea how to write clean code and those parts of codebases and those people should be avoided as much as possible. I'm not trying to hate, but wow some devs have no shame.

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

#45

Post by adlpz »

andirk wrote: post #44

Haven't read but it's definitely time to start demanding people write clean code. My house often gets messy, and so does my code. And then I clean my house and refactor my code. I try to steer away from refactoring for the sake of making my code look sexy, which it does, but putting time on the calendar for an almost guaranteed need to shuffle things around when you get a chance feels good and makes your future self…

The issue is that the meaning of "clean code" here isn't code that's clean and legible.

It's code written in the typically over engineered OOP-heavy Java style. Think lots of "patterns", massive amounts of inheritance, interfaces and factories everywhere.

I made the decision of abandoning any clean-code-ish practices within my teams long ago.

I still demand the code to be structured sensibly, be clear, well named and documented.

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

#46

Post by riffraff »

swatcoder wrote: post #10
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…

Obviously, both of your extremes are totally unmaintainable and it doesn’t matter which somebody prefers of the two. What I think matters in the general case is the likely mutation rate of the code, and the familiarity of its design. Both of these are speculative, subjective factors, so right-sizing a function is basically a gut feeling. It can prove wrong in hindsight and others can disagree with your choice from th…

> Obviously, both of your extremes are totally unmaintainable and it doesn’t matter which somebody prefers of the two.

But we work with 1000 five lines functions all the time in high level languages.

All the stuff done on array/list/hash and the likes (map,fold/inject/reduce,sum,select,reject..) are five lines functions.

Why would you not want that for your own types?

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

#47

Post by dang »

andirk wrote: post #42
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)

It's probably time to stop recommending "It's probably time to stop recommending Clean Code"

Reposts are fine on HN after a year or so, if the article is good for HN*. If the article is bad for HN, best not to post it in the first place. I don't know about this article.

* https://news.ycombinator.com/newsfaq.html

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

#48

Post by ornornor »

From my decade writing software professionally and my current job search, I really question the actual demand for clean code.

That’s unfortunate because it’s my specialty and what gives me job satisfaction.

I love fixing things. I actually enjoy working on a crappy codebase that has made the company money but is now too hard to maintain/extend and needs cleaning. Adding tests, refactoring, extracting functionality to discrete functions, figuring out what the black box actually does, etc. This is what I’ve specialized in.

However, it seems to me that companies don’t actually value that. They all say they do of course, while actually being afraid of doing this because it takes more time and money. Even if they’re mature enough that survival isn’t an immediate concern anymore, there is time to clean things up, and the mess is actually slowing them down through downtime, bugs, and not being able to ship relatively trivial features/updates in less than weeks.

I also suspect that not focusing on clean code is a strategy many managers have because they can show velocity to their higher ups and get promoted before it all blows up and they’re held responsible.

So what do you all think? Is clean code really actually valuable in the eyes of organizations or will they always take the quicker and dirtier option given the choice? Will I ever find work selling code cleaning (even to companies that ask for it) or should I “rebrand” on fast and cheap code at the expense of quality?

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

#49

Post by swatcoder »

riffraff wrote: post #46
swatcoder wrote: post #10

Earlier quoted context omitted.

Obviously, both of your extremes are totally unmaintainable and it doesn’t matter which somebody prefers of the two. What I think matters in the general case is the likely mutation rate of the code, and the familiarity of its design. Both of these are speculative, subjective factors, so right-sizing a function is basically a gut feeling. It can prove wrong in hindsight and others can disagree with your choice from th…

> Obviously, both of your extremes are totally unmaintainable and it doesn’t matter which somebody prefers of the two. But we work with 1000 five lines functions all the time in high level languages. All the stuff done on array/list/hash and the likes (map,fold/inject/reduce,sum,select,reject..) are five lines functions. Why would you not want that for your own types?

If they’re operations used in a hundred places, then they should be whatever size they need to be.

Of course there are a lot of 5-line functions in that set, and also some 500-lines functions and also many functions that recurse or stack very deeply, and also some very shallow ones. They’re polished stones.

But function length isn’t a useful goal in itself and if it’s made to be, you’re deprioritizing the many other factors that matter.

Post reply on HN