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

“Clean” code, horrible performance

computerenhance.com

Post reply on HN
Print view View original

51–60 of 932 posts

Re: “Clean” code, horrible performance

#51

Post by mpweiher »

vrnvu wrote: post #45
mpweiher wrote: post #34

Earlier quoted context omitted.

> TDD or XP methodologies > the more concepts and abstractions you apply to your code the better programmer you are! These contradict each other. XP very explicitly opposes introducing (unnecessary) abstractions: YAGNI, DTSTTCPW, etc. And TDD is a good tool for enforcing that, as you only get to write code that you have a failing test case for.

> TDD is a good tool for enforcing that, as you only get to write code that you have a failing test case for. TDD encourages the use of mocks and unit testing to increase code coverage. And unit testing is specially dangerous. You write a test, then program, so the test is helping you (the programmer). Selling the idea that the higher the test code coverage is the better and safer your code is. Not true at all. If yo…

> TDD encourages the use of mocks and unit testing to increase code coverage.

No, it encourages reasonable decoupling, i.e. good design.

If you see yourself introducing mocks (I think you mean stubs, mocks are something more specific) everywhere, you are feeling the pressure, but avoiding the good design.

https://blog.metaobject.com/2014/05/why-i-don-mock.html

> Most unit tests are written to ease the development.

Yes, unit tests help significantly in development.

> After finishing the development, they are safe to delete.

Noooooooooooooooooooooooooooooooooooooooooooooooo!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

They are your guardrails against regressions.

> If you follow TDD, most unit tests are re-written all the time.

Nope.

Re: “Clean” code, horrible performance

#52

Post by tippytippytango »

robalni wrote: post #49
tippytippytango wrote: post #36

I wish software engineering cared a lot more that we have no way of measuring how clean code is. Much less any study that measures the tradeoffs of clean code and other concerns, like a real engineering discipline.

The funny thing is that the things that are not possible to measure will be undone all the time because people can't agree on how it should be. This means that there will be wasted time. First we have to write the code this way. Next year we have to write it in the other way. Then it has to be done in the first way again. It's so hard to prioritize things when you ask someone why something has to be done the way they…

This happens because software engineering doesn’t yet know the difference between principles and morals.

Re: “Clean” code, horrible performance

#53

Post by tizzy »

js6i wrote: post #10
spoiler wrote: post #7

Earlier quoted context omitted.

It doesn't just make devs easier to replace. It makes it my job more pleasant (and that of my colleagues). But yes, you're right. It does also help onboard people. Imagine working as a barista with a disorganised bar, a mat on the floor that keeps sliding and a corner is sticking up, and one bag of beans where half the side is decaf and the other is normal. Now compare that to working in a more common sense coffee sh…

Huh? Coffee shops optimize for people not bumping into each other and having related items close together, and don't pretend to not know what kind of gear they have.. that's not a terrible analogy to the exact opposite argument.

I think the sentiment is that order and organisation is helpful in achieving goals and cultivating a good working environment as opposed to a big mess. Analogies, just like abstractions, are leaky.

Re: “Clean” code, horrible performance

#54

Post by tippytippytango »

vrnvu wrote: post #11

The problem with the contemporary "clean code" concept is that the narrative that performance and efficiency don't matter has been pushed down the throat of all programmers. Re-usability, OOP concepts or pure functional style, design patterns, TDD or XP methodologies are the only things that matter... And if you use them you will write "clean code". Even worse, the more concepts and abstractions you apply to your cod…

Sounds like clean code used to mean things that were measurable.

Re: “Clean” code, horrible performance

#56

Post by bombolo »

theknarf wrote: post #55

This seems more like an argument against the object oriented model of C++ than anything else. Would have been more interesting if the performance was compared to languages like Rust.

I think it could be ok to have a link every once in a while that doesn't talk about rust.

Re: “Clean” code, horrible performance

#58

Post by abyesilyurt »

theknarf wrote: post #55

This seems more like an argument against the object oriented model of C++ than anything else. Would have been more interesting if the performance was compared to languages like Rust.

My key learning is the importance of balancing performance and code cleanliness instead of blindly adhering to clean code principles.

Re: “Clean” code, horrible performance

#59

Post by gjadi »

lwhi wrote: post #39
krona wrote: post #31

Earlier quoted context omitted.

Nobody is saying maintainable code isn't important but rather that clean vs fast is a false dichotomy.

Okay, so we should aim for clean AND fast code?

One can argue that simple code is both fast and clean. However, you can only measure how fast (or slow) your code is, so make it simple, aim for fast and hope it's clean (:
Post reply on HN