Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"Clean" Code, Horrible Performance (2023)

computerenhance.com

Post reply on HN
Print view View original

171–180 of 192 posts

Re: "Clean" Code, Horrible Performance (2023)

#171

Post by antonymoose »

wasmperson wrote: post #63
Aurornis wrote: post #12

I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…

> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain ba…

I would charitably say that it’s a function of a different time and place in programming. The way you write “Clean COBOL,” “Clean Java 6/J2EE,” and “Clean Rust” are all going to be very different.

There is still good meat-on-the-bone in the book, and especially interesting if you’re working in a legacy system from that older time and place.

Re: "Clean" Code, Horrible Performance (2023)

#172

Post by ozim »

98codes wrote: post #80
Aurornis wrote: post #12

I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…

Adopting anything as blind dogma is Expert Beginner territory. See also: DB table normalization.

I basically spent 2 full years removing normalization from our two projects that was originally added because devs followed best practice.

Those 2 years were to do the data migration and of course there were different priorities, if that would be priority we would do it in 1 month, but we liked to spread risk over time.

Reason was of course performance issues and not really needed joins, where normalization didn't bring any benefit.

Re: "Clean" Code, Horrible Performance (2023)

#173

Post by cestith »

win311fwg wrote: post #170
wasmperson wrote: post #63

Earlier quoted context omitted.

> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain ba…

> It frames people who don't do "Clean Code" as unprofessional and lazy Well, isn't that the whole reason for the profession? If you want to be professional and hardworking, why are you instructing a computer to do your work for you? If you aren't being unprofessional and lazy, you're in the wrong business.

Larry Wall said the three virtues of a programmer are laziness, impatience, and hubris. He meant when properly applied, of course.

Re: "Clean" Code, Horrible Performance (2023)

#174

Post by cestith »

ozim wrote: post #172
98codes wrote: post #80

Earlier quoted context omitted.

Adopting anything as blind dogma is Expert Beginner territory. See also: DB table normalization.

I basically spent 2 full years removing normalization from our two projects that was originally added because devs followed best practice. Those 2 years were to do the data migration and of course there were different priorities, if that would be priority we would do it in 1 month, but we liked to spread risk over time. Reason was of course performance issues and not really needed joins, where normalization didn't br…

In an ideal world the data at rest would be normalized and you’d have a view or a derived table or something when needed to make queries fast when necessary.

If you ever find a job in an ideal world, hold on for dear life and please accept my CV for consideration.

Re: "Clean" Code, Horrible Performance (2023)

#175

Post by cestith »

exe34 wrote: post #166
mattmanser wrote: post #152

Earlier quoted context omitted.

50-60 lines? You must have tiny text size, on mine, with VS Code, I can see 40 lines. As you get past 30 and your eyesight starts changing, you need to up it. By 45 you need it quite a bit bigger than you used to have it. In the mid-2000s there used to be a lot of articles reminding the mainly young developers that 11-12px font size was unreadable to anyone past 40. On top of that, the default place for a console in…

I always assumed it was wisdom that made functions smaller and the font bigger, but you may be right- it's ageing!

We hope to wisen as we age, but there’s no guarantee.

Re: "Clean" Code, Horrible Performance (2023)

#176

Post by ryanbrunner »

locknitpicker wrote: post #158
ryanbrunner wrote: post #33

Earlier quoted context omitted.

Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. There is absolutely a place for PR reviews, and I don't think the person you were replying to was against that, just that PR reviews would be better by actually judging things like readability directly rather…

> Fortunately we are humans, and professionally trained humans at that, and we can judge readability and comprehensibility of methods through better measures than whether it crosses a boundary of number of lines. Lines or code is an indicator, not a goal. If you write long-winded functions, your code is bug prone and harder to test and verify. If you refactor it, it gets shorter. Where do you draw the line? The same…

I think what I intended to get across isn't too incompatible with what you're saying. I think it's fine to say "this function is too long", and long functions generally speaking should be something that's worthy of a code review comment.

I think the issue that originally launched this thread of the discussion is people who take the specific rules to a dogmatic level and apply rules blindly, and transform "functions should not be long" to "functions should be less than 20 lines no matter what". 20 lines (or whatever standard you land on) should be a guideline and not an inviolable law of the universe, and if reducing a method below 20 lines harms comprehensibility and readability, you're letting the guideline get in the way of the actual goal.

Re: "Clean" Code, Horrible Performance (2023)

#177

Post by TheCoelacanth »

josephg wrote: post #116
TheCoelacanth wrote: post #110

Earlier quoted context omitted.

No, it's a false dichotomy. When working on large applications, by far the single most important factor in performance is having simple and understandable code. Understandable but slow code can be fixed. Incomprehensible code can't, so it either stays slow or gets worked around with caching/async processing/etc. If you want fast software, you should write the simplest thing that isn't obviously stupidly slow, then me…

This is only true up to some point of skill & complexity. Hotspot optimisation only takes you so far. Eventually you can end up with a program that is fast everywhere but which is still somehow slow at the macro level. Like LLVM. Truly fast software is made by thinking about data flow from the start. If you use the right data structures, the code takes care of itself. But this is far beyond Clean Code. The examples i…

Choosing the right data structure isn't in opposition to making simple, readable code; it's part of it. Nothing over-complicates code more than a bad choice of data structure. If you pick the data structure that simplifies your code the most, the vast majority of the time that is also the right choice for performance.

I disagree with much of the advice in Clean Code, but it has nothing to do with performance. Clean Code is bad because it produces overly-complex unreadable code. The reason that it produces poor performance isn't because the code is too readable; to the contrary, if the code was more readable it would be more obvious that it's using the wrong data structure.

I'm not saying that you shouldn't think about performance from the beginning. I'm saying that you shouldn't sacrifice simplicity and readability for the sake of performance until you are sure it's necessary because those things are rarely in opposition to each other on the macro scale.

Nothing is worse for performance than doing work you don't need to do and unreadable code tends to do a lot of that if it has been actively maintained for more than a year or two.

Re: "Clean" Code, Horrible Performance (2023)

#178

Post by RaftPeople »

antonymoose wrote: post #171
wasmperson wrote: post #63

Earlier quoted context omitted.

> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain ba…

I would charitably say that it’s a function of a different time and place in programming. The way you write “Clean COBOL,” “Clean Java 6/J2EE,” and “Clean Rust” are all going to be very different. There is still good meat-on-the-bone in the book, and especially interesting if you’re working in a legacy system from that older time and place.

> I would charitably say that it’s a function of a different time and place in programming.

I really think it was just one persons opinion that got published. I started in the 80's and at each software company I worked at they had standard styles that I think we're very clean and organized without being overly dogmatic in any one direction.

Re: "Clean" Code, Horrible Performance (2023)

#179

Post by RaftPeople »

98codes wrote: post #80
Aurornis wrote: post #12

I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure, but harmful to late-stage developers who adopt it as dogma. On a long enough career path, eventually you will run into one Clean Code zealot who carries an air of superiority and nit picks every PR over things like a function having more than an arbitrary number of lines in it instead of reviewing…

Adopting anything as blind dogma is Expert Beginner territory. See also: DB table normalization.

> See also: DB table normalization.

Pragmatic approach: generally end up with an average of around 2.72 normalization across all tables.

Re: "Clean" Code, Horrible Performance (2023)

#180

Post by win311fwg »

antonymoose wrote: post #171
wasmperson wrote: post #63

Earlier quoted context omitted.

> I consider Clean Code to be in the category of books/styles that is helpful for early developers who need some structure Clean Code is unhelpful to beginners too, though: misuse of industry-standard terms, shunning of comments in favor of tiny functions with long names, shunning function arguments in favor of mutating state, polymorphism obsession, etc. So much of the concrete advice the book gives is just plain ba…

I would charitably say that it’s a function of a different time and place in programming. The way you write “Clean COBOL,” “Clean Java 6/J2EE,” and “Clean Rust” are all going to be very different. There is still good meat-on-the-bone in the book, and especially interesting if you’re working in a legacy system from that older time and place.

Not to mention that "Clean Code" is from the era where many developers were still sticking MySQL calls into the middle of their HTML. It was trying to wrangle an audience that didn't put any real thought into code, trying to convince them that they should. That is an audience that doesn't meaningfully exist now. While there are still disagreements on exactly what the code should look like, most everyone now agrees that it is something worth thinking about, in large part because of efforts like "Clean Code" putting bugs in ears. It isn't what you would write today, but it wasn't written today.

Without fail, if a developer is "pissed off", it is because they are judging something from the past by ignoring the conditions of the past.

Post reply on HN