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

181–190 of 216 posts

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

#181

Post by gs17 »

Groxx wrote: post #59

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

I also found it to flip between "this is obvious advice" and "this is awful advice", and I think that's part of the issue. I've had multiple arguments with people where that natural motte-and-bailey led to "oh, you don't like Clean Code? so you think variables shouldn't have understandable names?"

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

#182

Post by prasooncc »

908B64B197 wrote: post #175
ornornor wrote: post #48

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…

> 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? There's many sides to this. Even Boeing doesn't value clean code (as shown by the 737 MAX disaster…

It would be prudent to include some data to substantiate your insinuation that some non white non European programmers did the Boeing MCAS code. The 9$ per hour wage maybe less than that of a burger flipper in the USA, but the cost of living is vastly different.Being an engineer , if you are ignoring this significant parameter then we definitely know one source of the issue .Maybe you are not an engineer but a fine arts major who “learned” coding by yourself.

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

#183

Post by wizofaus »

Jensson wrote: post #13
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"…

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

If by "arbitrarily" you mean "at east 4/5 line boundary", perhaps, but in that case it's virtually impossible to give the smaller functions meaningful names. Personally I wouldn't tick a PR with functions more than about 30 lines generally, pretty much the only exception would be something like a simple switch statement that happens to need to deal with 50+ cases, and does so with a single function call for each case* (it may be preferable to do that using a data structure to map input cases to function pointers, but generally that makes code harder to debug too). Arguably that's "forcing" other devs to stick to small functions. I've never seen a 1000+ line function that has anything like any decent sort of unit test coverage, for a start.

*) message handlers in raw Win32-apps come to mind

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

#184

Post by wizofaus »

Jensson wrote: post #24
jacquesm wrote: post #19

Earlier quoted context omitted.

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.

I'd even say ANY 5000-line function can always be improved by breaking it up into 1000 5-line functions, but it would be rare that would be the ideal way to rewrite it either.

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

#185

Post by superjan »

Jtsummers wrote: post #173
superjan wrote: post #125

Earlier quoted context omitted.

If this verbiage is only in the introduction, it will not carry much weight. People, and especially IT people like rules, that you can indiscriminately apply.

If people claim to read a book and skip chapter 1, did they really read the book? I'd say no, they only read part of it. It's not the authors' fault that people skip a chapter that generally provides the context for reading the rest of the book. That's on them. Don't be foolish, learn the context of what you're reading before you read it. That is what should be encouraged.

My point is that people are better at remembering and applying specific rules. And it is my perception that people involved in software development like explicit rules. This is partly due to the exponential growth (and thus low level of experience) and also because it feels more objective.

“Code should be readable” is a higher level goal that is inevitably subjective, so it is harder to enforce than for instance, DRY.

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

#186

Post by seadan83 »

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…

Clean code does emphasize that the structure of the class file and layout of functions should strive to allow for the entire class file to be read in a single pass from top to bottom.

Though, I'd agree that is quite different when someone puts in a linter that requires 5 line methods and scatters the flow of logic.

IMHO, "imperative shell with functional core" (which implies consistent levels of abstractions) is a follow up the book could really use.

To another extent, I think small and controversial rules of thumb like "keep functions short" can easily be taken out of context. A refactoring I often see that can be done when methods are poorly broken up is class variables can be converted into local variables once some of the methods are inlined.

The point of the small function is so that a developer can keep track of fewer moving parts in their head while reading. If the shattering into functions causes the class to have 30 class variables in order to support that, then it's very much a case of following the wrong heuristic. IIRC, clean code holds a highest priority on the developer only needing to keep track of 3-5 things at a given time (and pretty much everything else is in service of that goal)

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

#187

Post by 908B64B197 »

prasooncc wrote: post #182
908B64B197 wrote: post #175

Earlier quoted context omitted.

> 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? There's many sides to this. Even Boeing doesn't value clean code (as shown by the 737 MAX disaster…

It would be prudent to include some data to substantiate your insinuation that some non white non European programmers did the Boeing MCAS code. The 9$ per hour wage maybe less than that of a burger flipper in the USA, but the cost of living is vastly different.Being an engineer , if you are ignoring this significant parameter then we definitely know one source of the issue .Maybe you are not an engineer but a fine a…

> It would be prudent to include some data to substantiate your insinuation

[0] https://www.businessinsider.com/boeing-outsourced-737-max-re...

[1] https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-...

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

#188

Post by Chris_Newton »

tommica wrote: post #83
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…

Clarity! That's my goal for my code: https://m.youtube.com/watch?v=6sNmJtoKDCo

IMHO, that was an excellent talk, well presented and insightful.

I found your argument starting around 28:00 interesting. I’m not familiar with the specific tools you’re using and their idioms, so it’s possible that I’m missing some context here. As a general principle, I like to make it very clear where code is doing I/O and what is happening with any data involved. If this function receives data in one format, transforms that data into another format and finally sends that data to the database, then to me that seems like a useful separation of concerns and a clear representation of the overall behaviour. Maybe I wouldn’t choose the same name/structure as User.registration_changeset in your example, but the principle of hiding the implementation details of the data transformation seems helpful, for the same reason it’s helpful to see Repo.insert() instead of five lines of SQL at this level of the code.

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

#189

Post by emodendroket »

ornornor wrote: post #91
emodendroket wrote: post #88

Earlier quoted context omitted.

Think of it this way. Imagine you hire an electrician to do some task. If while he's there he cleans up some stuff around where he was working, that's welcome. If he starts rewiring your whole house for no particular reason, even though everything was working fine, and billing you by the hour, you might not be pleased.

Absolutely but this isn’t the situation I’m talking about here. To reuse your analogy, I’m talking about a restaurant who has a mess of an installation, several panels and breakers, not all up to code, and the electricity frequently shuts off taking hours to figure what happened and how to restore it. It’s also a mild fire hazard and there have been a few close calls that could have burned the place down. The son in…

Well, to put it another way, "clean code" can be the means of achieving an end, but if you tell them you're replacing existing code with clean code that sounds like a waste of time. You should be able to describe some concrete goal you are working towards and they should leave it to you to worry about how you do it.

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

#190

Post by prasooncc »

908B64B197 wrote: post #187
prasooncc wrote: post #182

Earlier quoted context omitted.

It would be prudent to include some data to substantiate your insinuation that some non white non European programmers did the Boeing MCAS code. The 9$ per hour wage maybe less than that of a burger flipper in the USA, but the cost of living is vastly different.Being an engineer , if you are ignoring this significant parameter then we definitely know one source of the issue .Maybe you are not an engineer but a fine a…

> It would be prudent to include some data to substantiate your insinuation [0] https://www.businessinsider.com/boeing-outsourced-737-max-re... [1] https://www.bloomberg.com/news/articles/2019-06-28/boeing-s-...

https://news.ycombinator.com/item?id=20353342#20355864 . Hope this link works . This discussion was 2 years ago.

Still my word holds good . Boeing management didn’t give crap about engineers opinion be it 30$ per hour or 5$ per hour.

Post reply on HN