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

“Clean Code, Horrible Performance” Discussion

github.com

Post reply on HN
Print view View original

101–110 of 220 posts

Re: “Clean Code, Horrible Performance” Discussion

#101

Post by kubanczyk »

goto11 wrote: post #89
pkolaczk wrote: post #86

Earlier quoted context omitted.

Ok. Fair enough. I just find that what Uncle Bob calls clean code is often not clean code for me. E.g. preferring inheritance over switch is less readable. Flexibility/extensibility and readability are different things.

> E.g. preferring inheritance over switch is less readable. Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex. Of course there are cases where a s…

> Surely this depends on the context?

Yes, it depends on the context. In this case the context is the switch statement described in the https://www.computerenhance.com/p/clean-code-horrible-perfor.... Too bad TFA never mentions it explicitly (other than in the title and in the video). Recently it generated a heated discussion around here.

Re: “Clean Code, Horrible Performance” Discussion

#102

Post by laserlight »

pkolaczk wrote: post #95
goto11 wrote: post #89

Earlier quoted context omitted.

> E.g. preferring inheritance over switch is less readable. Surely this depends on the context? If you have a many different classes it tend to lead to cleaner code if you encapsulate the class-specific logic with the class definition rather than intermingled in multiple giant switch statements. In particular you can add new classes without making the rest of the code more complex. Of course there are cases where a s…

Switch statements don't have to be giant. Hint: you can still extract each branch to a separate function / module. But what is more readable about them is the control flow: the condition is explicit and all targets are easy to find. A codebase using switches/ifs and function calls can be easily navigated with ctrl-click in most IDEs. A codebase relying heavily on interfaces and inheritance cannot.

If you aren't going to use polymorphism to vary behavior, but depend on conditionals, what do you use classes for? Just for hierarchical data encapsulation?

Re: “Clean Code, Horrible Performance” Discussion

#103

Post by regularfry »

lucumo wrote: post #96
foo42 wrote: post #40

Earlier quoted context omitted.

that last paragraph is an excellent description of the problem!

It's really not. Software solves business problems. Code that meets its requirements needs to be left alone. Developers just changing code because they feel like it need some coaching. They're wasting everybody's time for reasons that amount to "I like it My Way". So, with normally performing developers, the only code that changes is the code that needs to change. Good or bad only has an influence on the cost of a ch…

That's not inconsistent with "good code will get rewritten until it's not good code." Good code that you need to change is code that can degrade as a result of that change.

Nothing to do with "just changing code because they feel like it".

Re: “Clean Code, Horrible Performance” Discussion

#104

Post by u02sgb »

RoyalSloth wrote: post #98
tester756 wrote: post #33

I'm starting to hate programming discussions, after you've read a lot of them they're predictable, boring as hell and you can argue endlessly just because you value a little bit different things. This discussions is yet another, nothing special way of saying: context matters. You have a list of requirements of what you want to achieve, some of them do appear during development and you develop against this. I have com…

Tab vs spaces war has cooled off, so we have to start a new one. A: If I do X, then this happens... B: Yeah but I don't care about X. A: You are not a professional if you don't care about what I care about. Now that this debate has raised some dust, I guess Bob has already started writing the "Clean Performance" book in order to continue to milk the series and stay in the spotlight.

Sounds like a "no true Scotsman" argument

Re: “Clean Code, Horrible Performance” Discussion

#105

Post by regularfry »

wirrbel wrote: post #31
pkolaczk wrote: post #8

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…

Robert C Martin's (who is not my uncle) Clean Code book/advice is what I would call junior programmer material. Its good to get someone started to think about better ways of writing software (albeit is hasn't aged very well). I don't recommend it to juniors anymore because it hasn't aged well and is for my taste hyperbolic in its promises. IMHO clean code also is more focused on code implementing "business logic" tha…

I am not fond of Clean Code, but I am fond of Clean Architecture. It's a much smaller set of ideas, for a start.

Re: “Clean Code, Horrible Performance” Discussion

#106

Post by lll-o-lll »

robalni wrote: post #26
pkolaczk wrote: post #8

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…

I used to like to rewrite code that I thought was "ugly" because it was not written in the modern way or it was not very generic or whatever. I thought that doing that was often pretty easy so I thought "why has no one done this already?" Later I realized that the fact that it was easy to change was what made it good and the changes I wanted to make to it would probably just make it more complicated. That's the dange…

This is why I think the most powerful abstraction for framework with extension points is c++ template meta programming. Wait! Hear me out!

Template meta programming is an entirely separate, incredibly complex, programming language distinct from c++. The only people I have ever seen use it in production are exceptionally skilled programmers. Everyone else flees and cowers. If they try to change it it will not compile. So why is this good? Because it only allows the framework to be extended in the ways intended by the original designer. Anyone wanting to update this unholy beast will be a master programmer who’s investing significant effort. That implies the updates will be good.

Good code is easy to change. Great code is near impossible to change, but easy to extend.

Re: “Clean Code, Horrible Performance” Discussion

#107

Post by Ygg2 »

tpoacher wrote: post #85
jackblemming wrote: post #57

Earlier quoted context omitted.

Strong disagree. This is something people say to sound clever. It’s not true at all. The real cause is basic entropy and complexity are always increasing. Rarely does a project manager request a feature be deleted. This is compounded by most companies having a few good programmers and mostly mediocre programmers, so the codebase will tend toward the mean over time.

so ... sounds like you agree?

What is the alternative? Bad code?

It's exactly same as arguing you should not educate your workers. Cause they might leave. So you get only the least knowledgeable ones.

Re: “Clean Code, Horrible Performance” Discussion

#109

Post by tinco »

It's just an anecdote but I think the emoji picker problem they explored is really what it is about. You can debate all day about whether Bob's clean code principles are valuable but the reality is that no pattern from any of his teaching will ever make a text editor get slow after just 300 typed characters in a single line.

I bet I'm Casey's life it happens often that he has to dismantle clean architecture in an application that is already quite fast just to squeeze out some extra performance. But that's not in the same arena of these every day performance annoyances.

It's some sort of variant on Amdahl's law. You could have a million lines of fairly performant code, and then in 3 lines someone fucks up and introduces an accidentally quadratic function into an emoji picker and your whole application will feel slow.

That's also the take away conclusion from this discussion. After listening to 8 hours of uncle Bob going on about clean code, he should pause and tell you to check over your codes performance when you're done. Since the clean code made you so productive, and your code so readable, it should be an easy thing to quickly check your performance.

Re: “Clean Code, Horrible Performance” Discussion

#110

Post by Ygg2 »

goto11 wrote: post #72
pkolaczk wrote: post #8

It is debatable if Clean Code actually improves the programmer efficiency and programs readability. I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. Even Uncle Bob's examples are not the state of the art in readability: https://qntm.org/clean The main problem seems to be that Clean Code is mostly a premature optimisation in code flexibility. It makes code more complex…

> I find people applying it religiously often create over-complex designs like FizzBuzz Enterprise. To be fair, this can be said about any technique. Lots of bad code results from people taking a reasonable principle and applying it religiously rather than judiciously.

On the other side of taking Muratori advice too far, is the story of Mel. Or to be more precise the guy that comes after Mel.

You have a ball of highly optimized mud, that quantum collapses if you glance at it too harshly, and we need it to be USB compatible. By Tuesday. Good luck!

Post reply on HN