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

131–140 of 216 posts

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

#131

Post by leftbit »

DanielVZ wrote: post #12
phendrenad2 wrote: post #3

Earlier quoted context omitted.

What's important is that people have the shared language of Clean Code (or some other repository of best practices, could be integrated into your company styleguide, for instance). I.E. If Uncle Bob said "Don't do X" then we can have a conversation in that context if, in this scenario, doing X is acceptable. Without that logical reasoning, people will debate the very existence of "not doing X" as a best practice.

Except having these discussions is really hard. It ends up being you against uncle bob and you are not gonna win that argument against a senior-er engineer.

Don't think so. If the senior engineer is worth his salt he should know that programming is always about finding a balance between several aspects of a given problem - some of them technical, some of them human. As long as the code does what it's supposed to do the rest is mostly up to personal taste - so yes, you can have an insightful discussion, but there's only to learn, nothing to "win" for all participants.

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

#132

Post by ornornor »

benj111 wrote: post #127
eurasiantiger wrote: post #94

Earlier quoted context omitted.

You stand up and talk about it publicly.

The issue is, managers want these things, like a nice code base, but are unwilling to pay for it. Or more correctly you have to pay most of the cost of that Hodge podge of hacks. So while they can off load that cost to you, why would they make an effort to improve the situation?

So what do we do? Working this way drives me crazy, depressed, and unhappy; I don’t want to do it anymore.

I don’t want to be part of the problem either by becoming one such manager so that others will have to pay the cost of my benefit.

What’s left? Opt out, live on shoestring budget for the rest of your life, and hope it works out?

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

#133

Post by MrJohz »

gorm wrote: post #118
MrJohz wrote: post #36

Earlier quoted context omitted.

I've recommended it before (I think there's even a blog post of mine written in direct response to this article floating around somewhere): A Philosophy of Software Design is really good. It isn't so concerned with all of the details about what exact decisions you should make ("how many lines should my function have?" etc), but rather the high-level design choices that go into those decisions. A lot of the book is sp…

I was also thinking about this book when I read that article. It's really an excellent book and it's condensed and because it's written by an expert in teaching it's easy to grasp. It's also recommended in this article: "Update, 2020-12-19 After suggestions from comments below, I read A Philosophy of Software Design (2018) by John Ousterhout and found it to be a much more positive experience. I would be happy to reco…

Haha, I read the article immediately after this comment and saw that comment, I think it wasn't there last time I read it (so presumably before the end of 2020!). I agree that it's probably not as good for complete beginners, but it's really good for anyone with a bit of experience looking to move from "I'm just writing code" to "I'm writing actual software".

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

#134

Post by leftbit »

iainmerrick wrote: post #78
matsemann wrote: post #75

Meh, I don't get the hate for Clean Code, or other books like this. Should you take everything it says as gospel? No. Did reading it in the beginning of my career make me a better developer? Yes. Its the same as with every other practice. Do I practice TDD? No. Did trying it out for some time learn me things I still apply to code I write 10 years later? Yes.

Don’t you think the example code quoted looks really bad? If the code is that bad, why should the advice be trusted?

Don't know if this is really a bad thing - had the same problems with the book, but the apparent contradictions made me really think about the stuff. So I'm quite prepared to consider his advice, I'd never turn it into gospel.

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

#135

Post by flippinburgers »

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…

Honestly anytime I run into someone spouting something "Uncle Bob" has tried to propagate in our industry while trying to sell books and his "knowledge" I find that it is safe to assume they are probably a perpetual junior level developer.

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

#136

Post by DotaFan »

leftbit wrote: post #129
DotaFan wrote: post #2

The amount of money I've spared to a companies by first learning the importance of Clean Code before I've tackled projects are immeasurable. Sure, Uncle Bob might be to opinionated and you might not like him, and some coding practices you might not agree with, and are indeed unnecessary today, but rules are important, and this is what we're missing today. Ground set rules, so everyone is on the same page.

> but rules are important, and this is what we're missing today. Programming rules are important - they make you think before you break them. Just don't turn rules into dogma - otherwise your devs will be more concerned with following the rules than solving the actual business problems. And you don't want that.

You should certainly be flexible around it, visit them every now and then to update. Also, we should enforce them once they are set.

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

#137

Post by ahartmetz »

eurasiantiger wrote: post #93
dietrichepp wrote: post #85

Earlier quoted context omitted.

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…

Let’s say my site has a download image feature that embeds per-user digital licenses into downloaded images at download time. This might take some processing so there is a queue and an abstraction representing the downloaded file. There are also several endpoints serving different types of image files. What shall I call the unit of code orchestrating these download processes, if not ImageDownloadManager?

ImageDownloadDispatcher, ImageDownloadScheduler, Image DownloadQueueManager... basically, the fix for "FooManager" names is to ask which aspect(s) of Foo the manager manages. Lifetime, storage, execution order (and according to which criteria), resource limits, uniqueness, exclusive access, efficient search, ...

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

#138

Post by ebiester »

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, within the context of Bob Martin "Clean", is one consistent mental model. I don't like all of it, but it gives one coherent top-to-bottom model.

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

#140

Post by mvdwoord »

ornornor wrote: post #102
eurasiantiger wrote: post #94

Earlier quoted context omitted.

You stand up and talk about it publicly.

Who listens, though? Look at seminal work like “the mythical man month”… while most people “in the trenches” agree that nine women can’t make a baby in one month, project managers and executives still very much think it’s possible 40 years later.

You can explain it to them, but you can't understand it for them..
Post reply on HN