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

41–50 of 932 posts

Re: “Clean” code, horrible performance

#41

Post by xnickb »

anonymoushn wrote: post #16
hennell wrote: post #13

I think he's really underplaying the main selling point of clean code - the objective of writing clear maintainable, extendable code. His code was faster, but sometimes how it compares for adding new features or fixing bugs by people new to a code base is where you want to optimize. Should performance be talked about more? Yes. Does this show valuable performance benifits? Also yes. Is performance where you want to s…

If someone is new to the codebase, would you rather they need to open a dozen files to see all of the different virtual functions that could occur at one call site, or open one file?

I see your point, but no one uses Windows notepad for coding anymore.

There are far worse crimes than having code structure that spans several files.

Re: “Clean” code, horrible performance

#42

Post by jasmer »

vore wrote: post #15

This guy is so dogmatic about it it hurts. I would argue that clean code is a spectrum from how flexible vs how rigid you want your abstractions to be. If your abstractions are too flexible for good performance, dial them back when you see the issue. If your abstractions are too rigid for your software to be extendable, then introduce indirection. We can all write code that glues a very fixed set of things end to end…

I don't think rich abstracions necessarily contribute to 'clean code' in fact often the opposite.

Clean code means easy to read, maintain, not full of arbitrary things 'because performance'.

Re: “Clean” code, horrible performance

#43

Post by robalni »

suyjuris wrote: post #38

It is also important to consider that better performance also increases your productivity as a developer. For example, you can use simpler algorithms, skip caching, and have faster iteration times. (If your code takes 1min to hit a bug, there are many debugging strategies you cannot use, compared to when it takes 1s. The same is true when you compare 1s and 10ms.) In the end, it is all tradeoffs. If you have a rough…

Yes. When I worked as a game engine programmer, two of the first things I did were to improve the speed of compiling and starting the games. When those two things are faster, all development will be faster and more fun.

Re: “Clean” code, horrible performance

#44

Post by dvaletin »

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…

> Even worse, the more concepts and abstractions you apply to your code the better programmer you are!

I had an Android programmer, who was eager to write clean code following GOF patterns, OP and the rest of the fancy things senior developers usually do. Ended up Android team with 3 devs required 3x time to develop same feature compared to single iOS engineer.

Re: “Clean” code, horrible performance

#45

Post by vrnvu »

mpweiher wrote: post #34
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…

> 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 your code doesn't have integration tests for example, you will never know how it actually runs. If you mock everything, you are not really "testing" anything but your internal logic. Unit testing and code coverage just checks that a code path has been run. But there are other tools like fuzzy testing or mutation testing... Do you randomize the memory at every test run? Do you make sure that the CPU cache is cold or hot depending on the test? Good testing is hard.

Most unit tests are written to ease the development. After finishing the development, they are safe to delete. Because they don't add any real value as I understand it. I understand that a test is a business contract of something that MUST work in a certain way. Unless the contract changes, the test must never be removed or changed. TDD and exhaustive unit testing make the maintenance process harder because you don't know if a test is useful or not.

If you follow TDD, most unit tests are re-written all the time. Because they were not written to test a business or critical contract, they were originally written to help some programmer write some internal logic.

Re: “Clean” code, horrible performance

#46

Post by pinto_graveyard »

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…

At least in the majority of places I worked at, people cared about readability and maintainability rather than just some abstract notion of "clean code".

And perhaps I was lucky, but typically readability and maintainability are orthogonal to performance and efficiency. Sometimes readable will have optimal performance, sometimes not. Then it becomes a matter of tradeoffs.

Re: “Clean” code, horrible performance

#47

Post by hotBacteria »

What is demonstrated here is that if you understand well the different parts of some code, you can recombine them in more efficient ways.

This is something very good to have in mind, but it must be applied strategically. Avoiding "clean code" everywhere won't always provide huge performances win and will surely hurt maintainability.

Re: “Clean” code, horrible performance

#48

Post by pinto_graveyard »

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…

> If you mock everything, you are not really "testing" anything but your internal logic.

That's the purpose of unit tests. They do not exclude the need to perform other kinds of test. Integration tests, contract tests, stress tests - all those will focus on different facets of a system.

> Most unit tests are written to ease the development. After finishing the development, they are safe to delete.

This is especially bad advice, unless no one will never touch that codebase ever again.

I saw old unit tests highlight bugs that would have been introduced by new code many times over the years.

> TDD and exhaustive unit testing make the maintenance process harder because you don't know if a test is useful or not.

Then, as a developer, remove unit tests that became useless.

Code coverage is a measurement. If you turn it into a goal, it will become useless. If you have "useless" unit tests, it tells me that some unit tests were written as padding to move code coverage up.

Re: “Clean” code, horrible performance

#49

Post by robalni »

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 say and they are not able to give a real answer. I can do my job when option A means faster program and option B means more memory usage but I can't do my job when option A means faster program and option B is just the way it "should" be done.

Re: “Clean” code, horrible performance

#50

Post by drainyard »

spoiler wrote: post #7
athanagor2 wrote: post #5

The performance difference is truly savage. But I think there is a reason for the existence of "clean code" practices: it makes devs easier to replace. Plus it may create a market to try to optimize intrinsically slow programs!

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…

It seems like you may be assuming that Casey is arguing against writing clear code, which he is not. He is arguing that you should just write the simple thing and usually that is also the most clear, readable and "maintainable" code because it is easy to get an overview of. So what he is arguing for does not fit your coffee shop example, because of course no one should write unreadable code. The argument is that sometimes taking a step back from how you were taught to write clean code, could be simplified in a way that is _also_ performant by default.
Post reply on HN