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

161–170 of 216 posts

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

#161

Post by kcartlidge »

vaughan wrote: post #143
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…

> 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

It's a very under-appreciated feature, but I know what you mean.

Alongside NCrunch, Wallaby is one of my most valuable purchases. For those not familiar with the feature being referred to, as a continuous test runner one of the great benefits is that the IDE plugins show the values of anything (variables etc) in your code, live. I don't mean some kind of hover-for-intellisense, but at the end of each line you see all the values for all the variables all the time.

So in real-time, as you code, any tests covering the code you're changing are being run and you can see holistically how everything you're working on is changing as you type.

Basic test runners run continuously on the command line. Better ones run in the background of your IDE, possibly adding coverage markers etc. Wallaby goes one step further and actually decorates your code with real values live in the IDE as you work.

It's very good (though, yes, tricky to set up and a little slow).

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

#162

Post by treeman79 »

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…

Been around awhile. Reached the point of. I really don’t care what style bosses use. Just be consistent.

Can’t stand being asked multiple times to change something depending on what order people review code.

I’ve learned to love auto linting for the sole reason that it instantly shuts down any discussion on styling.

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

#163

Post by ianai »

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.

What you described reflects that corporate structure and might be industry wide. They look at code as only valuable in the monetary return it makes. They might even consider it a cost center. That will always be a less than pleasant place to work in an organization.

So find places and maybe start at industries that consider their code an asset or profit center.

It’s ultimately just a valuation perspective, but understand to a business everything has a market context or business case. It’s can be infuriating, but better to know the system than blindly suffer through it.

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

#164

Post by DanielVZ »

ravagat wrote: post #150
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.

Thanks! I haven't written much really. I killed my personal site some months ago, and this is the only public blog post I have now, but it's more related to my current side-project and how I got into programming:

https://pomasearch.com/blog/why-is-this-site-named-poma-and-...

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

#165

Post by DanielVZ »

AlexSW wrote: post #32
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…

Which SOLID principles have you found issues with, either theoretically or in practice? They still seem like broadly sensible principles to me.

For example the Open Closed principle is often times used to justify a plethora of inheritance chains rather than having a more generic class that can handle cases based on some parameter. Specially when all a subclass does is modify some class attribute or change some implementation by one line. Obviously some times it's good to apply the principle, but not EVERY time it fits.

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

#166

Post by DanielVZ »

leftbit wrote: post #131
DanielVZ wrote: post #12

Earlier quoted context omitted.

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.

Yep, but in practice Seniority comes either from experience or time in the industry. So you'll undoubtedly meet seniors that won't try to find that balance.

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

#167

Post by DanielVZ »

Jtsummers wrote: post #39
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…

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…

I didn't remember that in the introduction. But if that was the case the book should've included more counterexamples and a less imperative language.

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

#168

Post by wadd1e »

SergeAx wrote: post #155
ebiester wrote: post #138

Earlier quoted context omitted.

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 is a kind of language. It is entirely possible to tell if person speaks clearly, easy to understand, or not. You may even train an ML model on Wikipedia section "Simple English". The same applies to code. It is not 100% deterministic metric, but it is relatively easy to argue and have a consensus upon.

>It is entirely possible to tell if person speaks clearly, easy to understand, or not.

Just thinking out loud here, but isn't correctness(grammar and spelling) the only thing we all(mostly) agree on? For example, someone well versed with old English literature may consider Shakespeare easy to understand, but I certainly wouldn't. I think "speaks clearly, easy to understand" are just as subjective as our notions of clean/idiomatic/readable code.

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

#169

Post by kcartlidge »

userbinator wrote: post #51
albertopv wrote: post #34

Earlier quoted context omitted.

You can have 1000 5-lines functions in all languages, not only java. Typescript FE projects can be as hard as java ones to read. It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases.

It seems to me that there's a lot of prejudice against java, maybe because it has been used by many low skilled devs developing poor quality codebases. I don't think that's the reason. The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much, and as a result you end up with what's classically known as "enterprise" code. I've seen the work of "low skilled devs" in other languages lik…

> The cultures of Java, C#, and now TS/JS definitely seem to worship abstraction far too much

Unfortunately true. C# has been around long enough that some of the more 'mature' developers I've worked with still treat the book as gospel. Trying to find the actual code that does actual work can be tricky. That's started to change in recent years fortunately - especially with newer developers joining thanks to the increasing popularity of Core.

As to the discussion: my basic rule of thumb is that single responsibility should be applied to every level of the stack, whether that be a single microservice, a single controller, a single function, or even a single property. Provided you follow that, many of the discussions vanish.

For instance, how big should my functions be? Big enough to do one thing. Any bigger and they are too big. Any smaller and they are too small. Regardless of lines of code.

So it narrows down to a simple decision - in the context of the code I'm writing, what is the one responsibility of this function? Following that practice it rarely ends up as a one-liner as it is hard (not impossible!) to encapsulate a complete piece of work in one line. It also rarely ends up more than a screenful as that usually means it's doing more than one thing.

The important point is to switch the question away from "How big should it be?" and instead consider "What is the sole thing it is responsible for?" [1]. Then write code accordingly. After all, we know from the bad old days of being paid per line of code that 'lines of code' is a useless metric.

---

[1] I'm aware that defining the responsibilities too tightly leads to fragmented code and a multitude of functions/abstractions. I'm also aware that defining them too loosely leads to huge functions and monolithic code flows. I'm not offering an answer, just saying we need to rephrase the question.

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

#170

Post by speleding »

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.

I agree but so much depends on context. This is like arguing a painting should not have too much blue paint. But what if you're painting an ocean?

In a programming context:

- If the business process you are trying to model clearly has 20 discrete steps is would be silly break them into 4 groups of 5 steps just to hit the ideal function size.

- Coming up with a good name for an abstraction in a moderately large program can be very tricky, but a poor name is hurting more than helping. Don't split it if you cannot think of a good name.

- If breaking out into a function requires passing in 10 variables then it may become harder to read than simply inlining it. You're probably not abstracting correctly in that case. Etcetera.

I've seen so many over-abstractions from junior programmers trying to be "clean" I wonder if these rules of thumb aren't hurting more than helping.

Post reply on HN