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

141–150 of 216 posts

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

#141

Post by gladiatr72 »

siva7 wrote: post #35
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…

That would lead to a Big Ball of Mud if given to an inexperienced or reckless developer as i've witnessed many times in my career. The problem with such best practices/patterns/thought pieces is that they stem from highly experienced developers but given to the inexperienced they are like a hand grenade in the hands of an ape.

It is like claiming you can teach someone how to read by having them watch and emulate already proficient readers. Hrm...

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

#142

Post by leftbit »

DotaFan wrote: post #136
leftbit wrote: post #129

Earlier quoted context omitted.

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

Really don't like the enforcing. Okay, mixed feelings there.

Rules should help you along, perhaps set a framework for your thinking. But they never should limit you in achieving your goal. When establishing a rule you should also specify what you want to achieve by it, how you'll measure its effects and under which conditions it should be removed.

Rigid rule enforcement has a strong danger of shifting the priorities of the developers to the detriment of your business.

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

#143

Post by vaughan »

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…

I think the problem with talking about understandable code is that we only talk about textual representation.

We should break out of the ide and visualize code more. I think then we would see the tangled mess we are creating. And then if we started talking about code that was cleanly visualized, we would truly have understandable code.

We need two-way sync for visualizations of all data structures and data flows. And then we need to see the actual data values inline as it flows through the system as we read the code.

Wallaby.js is a great leader in this space. I found it too hard to setup and too slow - but I’m convinced this applied to the entire stack is the future.

We draw diagrams on the whiteboard to explain every system but they are completely absent when we actually code.

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

#144

Post by Jtsummers »

userbinator wrote: post #56
Jtsummers wrote: post #39

Earlier quoted context omitted.

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.

Quoting the person I responded to, who wrote:

> the book was inconsistent and dogmatic.

How do you square that with:

> The claim is not that the book is dogmatic

You are claiming they didn't write what they wrote.

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

#145

Post by [deleted] »

edflsafoiewq wrote: post #116
Jtsummers wrote: post #39

Earlier quoted context omitted.

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…

It's dogmatic in the sense that it often pursues some point (such as very short functions) to the level of a dogma, without much regard for the benefit accrued.

[deleted]

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

#146

Post by noisy_boy »

ornornor wrote: post #86
noisy_boy wrote: post #62

Earlier quoted context omitted.

> They all say they do of course, while actually being afraid of doing this because it takes more time and money. That is my experience too with most places - they say that they support clean, well tested and maintainable code and then turn around and ask things to be delivered in unreasonable time resulting in quick and dirty code. > I also suspect that not focusing on clean code is a strategy many managers have bec…

So… how do you deal with this on a personal level? How do you retain any shred of sanity or enjoyment from your work? I can’t stand self inflicted toil and the stress from constant firefighting which is invariably the result of these short term policies. It makes me want to quit programming altogether and work in something totally unrelated even though I love programming. Just not the way employers want it.

You switch jobs. Of course, there are managers everywhere and of course generally they have similar motivations. However, every once in a while you get one who was a developer-at-heart once (or still is) and does give some amount of shit even when they are looking for their usual goals. If that person doesn't happen to be evil, you stick with that team until things change (maybe the manager moves on). The good thing is that when good managers move, they tend to take the good and trusted ones with them to the new place. Assuming they saw your efforts and value your skills, you can move with them. Alternatively, if they are not the type to do so/you can't move with them, switch again. Either way, side effect is that your pay goes up too due to the switching - just don't do it too frequently.

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

#147

Post by leftbit »

admo1 wrote: post #89

Am I the only one who thinks it's a great book and that it should still be among the top books to be recommended ? Maybe not the first one but easily in the top 10. Each time I see the same discussion on HN about this book, I'm always wondering why I see so many people going in either direction : not following the advice of the book at all, or following it too religiously. For me, the philosophy of the books was alwa…

Exactly that - the subtitle really says it all: "A Handbook of Agile Software Craftsmanship"

A craftsman is an expert in his field who applies his knowledge and techniques judiciously, not religiously or automatically.

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

#148

Post by ravagat »

The biggest (in terms of impact) detriment I've seen of Clean Code has been a lot of diluted information passed down from and to devs who haven't bothered to read the actual book. A lot of context gets lost in translation and really the the term "Clean Code" became more myth/stereotype like.

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

#149

Post by ploppyploppy »

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…

*Testable, correct & easy to understand

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

#150

Post by ravagat »

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…

Good points, interesting context coming from a history student and now with some experience, I'd like to read more on your thoughts if you have a blog.
Post reply on HN