61–70 of 932 posts
At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).
"Game developer optimizes code for execution as opposed to readability that 'clean-code' people suggest".
There are few considerations:
- most code is not CPU bound so his claims that you are eroding progress because you are not optimizing for CPU efficiency is baseless
- writing readable code is more important than writing super optimal code (few exceptions: gaming is one)
- using enums vs OOP is not changing the readability at least to me
I think we can have fast and readable code without following the 'clean-code' principles and at the end it does not matter how much gain we have CPU cycle-wise.
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…
That was the case during the 90s and the first decade of the 2000. Just wait for Moore's Law to kick in and in 18 months your code will get faster by an order of magnitude for free.
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.
Casey prizes performance over everything else.
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…
I vaguely smell the language of choice has something to do with that, and C++ would benefit more from data-oriented design than from literate OOP or functional programming patterns took from very very different programming ethoses (the programming language is an interface to something else)
I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).
Really enjoyed watching some guy Breathlessly discover data oriented design https://en.wikipedia.org/wiki/Data-oriented_design there's nothing novel in this video, really nothing to do with clean code. This is same sort of thing you see with pure python versus numpy
This video from 2015 where Casey is interviewing Mike Acton: https://www.youtube.com/watch?v=qWJpI2adCcs
Also this course where he specifically talks about Numpy and pure Python: https://www.computerenhance.com/p/python-revisited
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.
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.
The first entry even stated that they were guidelines and if you have a valid reason to deviate: discuss it and you'll get an exception.
The discussion thing was mainly for new coders. We had a library part of the code that was used by many programs. Optimizing parts of it for their use case, could make it unusable for the others who used it.
Communication is key. If you discuss, before implementing it, why you're making certain design decisions then everything goes a lot smoother. If there are objections, keep in mind that the worst case isn't throwing away your design and starting over. The worst case is implementing it and screwing over your fellow coders.
I don't think there is a contradiction or surprising point here. At least my understanding of the case for clean code is that developer time is a significantly more expensive resource than compute, therefore write code in a way which optimises for developers understanding and changing it, even at the expense of making it slower to run (within sensible limits etc etc).
Externalised cost on the environment will hopefully one day be addressed.