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

151–160 of 192 posts

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

#151

Post by 0x20cowboy »

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…

Which would be fine if these people weren't the ones making / influencing the hiring decisions, paying them half a million dollars (even though they have done nothing) and people retweeted their “opinionated” takes on subjects they barely understand.

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

#152

Post by mattmanser »

giancarlostoro wrote: post #62
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…

The function size is one rule from Clean Code I disagree with, it's silly. I love helper methods, but use them to a reasonable standard. I'd argue, if you cannot see it all on a 1080p monitor, that it might be getting a bit too long. I read PEP-8 religiously before I learned about "Clean Code" and it helped me to have sane standards in general. Methods that are roughly under 100 lines of code are okay, better is to f…

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 VS Code is at the bottom, now I'm down to 25-30 lines if I have that open.

And then there's heavier IDEs like IntelliJ, Visual studio, etc.

They might have two or three tab lines at the top, a row used for class navigation (that I've just realized I've never, ever used), an extra row or two of quick action bars, a row of extra tabs at the bottom for navigating between consoles/call stacks/locals/error lists, 2 info bar rows at the bottom, and sometimes two or even three scroll bars stacked on top of each other.

All of a sudden you're down from 30 lines visible to 17, which is my actual visible lines of code when I have debugging running.

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

#153

Post by Gibbon1 »

giancarlostoro wrote: post #62
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…

The function size is one rule from Clean Code I disagree with, it's silly. I love helper methods, but use them to a reasonable standard. I'd argue, if you cannot see it all on a 1080p monitor, that it might be getting a bit too long. I read PEP-8 religiously before I learned about "Clean Code" and it helped me to have sane standards in general. Methods that are roughly under 100 lines of code are okay, better is to f…

I keep coming back to the idea he's advocating using long function names as a substitute for comments.

Instead of // do the thing followed by 5 lines of code to do the thing. You're supposed to put those five lines in a function named DoTheThing(). That doesn't seem better to me.

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

#154

Post by yeoyeo42 »

taybin wrote: post #19

Yes, a toy problem only needs a simple implementation. This is a straw man. And I don't even like Robert Martin's Clean Code, but the author is not addressing where this style actually provides benefits. When you're updating 23 if-statements because you had to add support for some new business workflow, you'll wish you had a conceptual entity that encapsulated the operations on the type of workflows so you just had t…

the toy problem is for demonstration purposes. this is a lived experienced in everyday programming of performance sensitive fields.

those apps tend to be vastly more architecturally complex in almost every way compared to your average corporate or web app too.

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

#155

Post by tcfhgj »

bluefirebrand wrote: post #134
dirtbag__dad wrote: post #125

Earlier quoted context omitted.

I think you’ve missed the point of clean code if this is your gripe with it. Every time you over scope a function signature, because you want to handle that other case, you add mental tax to the next person. This accumulates, burns time, and now confuses agents, which is time and tokens ($). No one wants to work with a dogmatic individual but I’d rather a nit picker than a human or agent slop machine.

Okay, but Clean Code* would advocate you extract that function to its own class with a new abstraction and it would ultimately wind up way more complicated than the extra params in a function signature

No I wouldn't - keep it short & simple

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

#156

Post by mathgeek »

bheadmaster wrote: post #138
Scubabear68 wrote: post #118

Earlier quoted context omitted.

The ugly reality is consultants like Martin have little production coding experience. Martin has posts going back to the early 90s showing he had little understanding of how software teams work and deliver value. From what I have seen, his ideas were formed in a vacuum divorced from real coding. You can see it in the small amounts of open source he has released. The kind of guy who will always prefer 50 classes to 5.…

Those who can't do, teach.

I really enjoy the somewhat sarcastic retort. Those who can’t teach: don’t.

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

#157

Post by tcfhgj »

captainbland wrote: post #143
jeffnash wrote: post #77

It seems like the main takeaway is that many textbook OO paradigms aren't the most optimized representations of the code. In this case, the cost is dynamic dispatch and pointer-chasing. This is a function of the Shape abstraction, but not the abstraction itself. But the argument is you're trading some of that performance optimization for maintainability. None of this is exactly news. And while I'm here ranting: I nev…

I think single dynamic dispatch is one thing but ends up reasonably well optimised by modern compilers, especially the JVM. I think most code written since the 2010s prefers the composition over inheritance pattern for the most part so tends to use interfaces rather than concrete base classes. That said, double dispatch as in the visitor pattern is often too hard to analyse for optimisation and I think humans frequen…

(seems like built in visitor in C++ is significantly slower than vtables)

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

#158

Post by locknitpicker »

ryanbrunner wrote: post #33
locknitpicker wrote: post #22

Earlier quoted context omitted.

[flagged]

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 goes for how many characters you accept between two line breaks. Some go for 76. Some for 130 or more. There is no difference if your line has 129 or 131 chatacters, but if you spew a comment with 999 characters in a single line then your feedback is actionable if you say "hey man, don't be that guy. Rewrite your comment and make it readable."

> (...) PR reviews would be better by actually judging things like readability directly rather than relying on measures that estimate those qualities.

Not really. Calling out basic things like "this function is far too long" is clear, objective, and actionable feedback. That is a good PR comment.

Dismissing clear and actionable feedback as some guys whims is a red flag, and a telltale sign of someone who has no interest to improve their output and address issues.

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

#159

Post by tcfhgj »

ErroneousBosh wrote: post #144
zabzonk wrote: post #106

Earlier quoted context omitted.

> If you aren't writing it in assembler, you're writing slow code. Depends in part in how good you are at writing assembler.

True, with modern processors there is a hell of a lot of "it has to be this way round for the pipeline to flow" that the compiler does for you. But you're still throwing away so much time on things like bounds-checking memory accesses that never need it.

> But you're still throwing away so much time on things like bounds-checking memory accesses that never need it.

Are you? C++ doesn't check bounds by default, and Rust only checks in certain situations and you could opt out if you wanted to instead of switching to asm

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

#160

Post by julian_t »

bheadmaster wrote: post #138
Scubabear68 wrote: post #118

Earlier quoted context omitted.

The ugly reality is consultants like Martin have little production coding experience. Martin has posts going back to the early 90s showing he had little understanding of how software teams work and deliver value. From what I have seen, his ideas were formed in a vacuum divorced from real coding. You can see it in the small amounts of open source he has released. The kind of guy who will always prefer 50 classes to 5.…

Those who can't do, teach.

I prefer the version attributed to Aristotle: "Those who can, do; those who understand, teach"

A good teacher needs a deep understanding of their topic, often deeper that that required to be a do-er only.

Post reply on HN