781–790 of 932 posts
I'm sorry to say that this argument is not even wrong.
As programmers, it is not useful to us to think about that 99.9% of time. The 0.1% of the time is literally our entire job.
"Most of the universe is not Earth, so why do we spend so much time thinking about things on Earth?"
Malicious compliance for C++ programmers. This is the person who thinks they're clever for breaking stuff because "You didn't say not to". Managing them out of your team is likely to be the biggest productivity boost you can achieve. In the process of "improving" the performance of their arbitrary benchmark they make the system into an unmaintainable mess. They can persuade themselves it's still fine because this is…
Fun fact. Software you routinely use, like Linux and Postgres, is written in the same "spaghetti" style. I guess the Clean Code people who implement CRUD features for a living are better programmers than the ones writing operating systems and databases. > Most of us work in an environment where surprising - even astonishing - customer requirements are often discovered during development and maintenance. Another fun f…
You'd like to pay money to be assured that you're right? I prefer to have an informed opinion based on actually trying stuff out and measuring†, I also find that as a result I don't feel the need to pay for validation.
> For example, he wrote a terminal emulator in a weekend to prove that Microsoft doesn't have a clue about how to write code
So, your thesis is that writing a terminal emulator - software which is pretending to be hardware that existed 40+ years ago, shows that this person is great at handling surprising requirements changes during development ?
An insistence that the only thing we can measure is performance and specifically speed and therefore that's the only thing that matters is nonsense. It's just that this technique does so poorly when judged on maintainability that it's no contest.
Try it, first add the hollow box example shape, in the Clean Code this is very easy and we'll notice immediately it's de-coupled, colleagues working with abstract shapes don't care at all about our Hollow Box shape, it all just works with the abstract APIs.
The less-clean switch approach is a little bit hairier now, but it's very possible although we may notice now our objects are all bigger again, even though perhaps few are hollow boxes, they're all bigger as they all need to track the possible state of a hollow box. So that's actually a significant performance degradation for some applications in our supposedly "high performance" solution...
The table-driven approach needs a rewrite though, the F*W*H simplicity doesn't apply any more, there are a few "minimalist" approaches, all of them awful compromises waiting for the other shoe to drop - so perhaps a big bang rewrite is called for. Ouch.
Now, having learned from our hollow box experience, let's add Regular Star Polygons next. These are pretty interesting shapes - but we're shape classes so no reason we can't handle this, the stars have a defined area and a defined number of vertices ("corners"). But while the Clean Code here is very tractable, the dirtier approaches start to hurt pretty bad now.
Notice that under Clean Code the exact implementation of Regular Star Polygons doesn't affect anybody else, their code all still works regardless. For example maybe we should sub-class popular examples like the 5/2 and 6/2 rather than taking p and q parameters, doing this works fine under Clean Code, since it's nobody else's business.
† EtA: One of the most important innovations in years has been Godbolt.org, Matt Godbolt originally worked on this tool to examine exactly this sort of question, it's one that comes up early in the talk you liked - can we safely use actual C++ iterators? Wouldn't an old-fashioned for loop be faster in some cases? Matt's answer was "Yes", you can use iterators, the iterators produce exactly the same machine code and the tool he used to demonstrate that evolved into Compiler Explorer, the godbolt.org site today.
Earlier quoted context omitted.
100%, I’ve done tonnes of (backend) performance optimization, profiling, etc. on higher level applications, and the perf bottlenecks have never been any of the things discussed in this article. It’s normally things like: - Slow DB queries - Lack of concurrency/parallelism - Lack of caching/memoization for some expensive thing that could be cached - Excessive serialization/deserialization (things like ORMs that create…
Maybe for low user count is valid. We run a large multitenant, microservice based application and the physical machines where the Kubernetes pods reside have their CPUs at 90%. The application makes such a large use of "clean coding", "design patterns", SOLID that would make Uncle Bob proud. We would have been better without using so much abstractions on top of abstractions.
Honestly, for most software, a well performant "monolith" is probably enough.
We had one service that had a single-thread bottleneck that none of the developers could configure out - the solution was to spin up 30x more virtual machines to run instances of this app to meet average production demand.
Earlier quoted context omitted.
Think of using slow patterns as using a slow programming language. After you've optimised your python program and eliminated all hotspots, the python profiler isn't going to say 'hey, this could be still 10x faster if rewritten in go'. Note that if you write a graphics engine, you aren't going to use python or even go, but something more like c, c++, rust, even though your code would be cleaner in python. Clean code…
>Clean code techniques elevate your level of abstraction and prevent some problems What problems do they prevent?
Earlier quoted context omitted.
Vue could also be an option, but I personally want to learn some Solid, as I see it could be preferred by the current mass of React frontend developers, more than Svelte and Vue. The syntax and philosophy of Solid looks closer to React, while having a stronger focus on performance.
Okay, I'll bite: does Vue perform better than React? Your post makes no mention of this, I don't know if it does, and offering it as an alternative due to performance reasons, without knowing this, seems a tad premature.
When react introduced hooks, it was fun for a while, but then we discovered the frequent re-render issues and had to change the way we think when building components and refactor old components. We have to manually wrap components in useMemo. This is the kind of things Vue has avoided me so far and React let me down. React relies on running all render methods instead of doing granular updates, I think this hurts performance. Vue listens to property changes and can perform granular updates.
I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…
In other words, the user’s entire perception of your program’s performance falls into that 0.1%.
Earlier quoted context omitted.
Casey is a bit of a hardcore crusader on the topic, but I'd hardly call dogmatic someone who can provide you evidence and measurements backing their thesis. The tests he put together here are hardly something I'd call a straw-man argument, they seem like reasonable simplification of real-cases.
These examples are absolutely a strawman. He's imagining there's one specific access pattern that's executed thousands of times per second. In a realistic codebase you're accessing the data less often but in multiple different (often subtly so!) ways. Cache efficiency is everything for modern CPUs, so you can't "simplify" the access patterns without making your benchmarks unrepresentative.
Clean code to me is like good writing. It should be easy to read and comprehend later. The rules are not rules but guidelines. I think OO centric rules are harmful in a word where languages support functional programming etc. Polymorphism isn’t always the best answer. A big nested if statement that reads like the business spec can be easier to follow and reason about. That aside if easy to understand code makes your…
Yep.. I much prefer 2000 lines of code in one function with very little calls. Easier to reason about, less bugs, easier to maintain. It's very easy to indicate when a new part is coming, just enter a big comment block of what you're doing.
Cramping code may be fine for high performance code where the mandays are justified for the two line code fix. But in most Software you likely just want to include the new cache methods, change the used object, add a button or fix an update. And the person fixing it probabaly hasn't seen the specific code ever before. There is sadly no need for high performance software, when you can't sell it in time.
I think the author is taking general advice and applying it to a niche situation. > So by violating the first rule of clean code — which is one of its central tenants — we are able to drop from 35 cycles per shape to 24 cycles per shape Look, most modern software is spending 99.9% of the time waiting for user input, and 0.1% of the time actually calculating something. If you're writing a AAA video game, or high perfo…
I don’t think the percentage of time waiting for input has anything to do with this. Outside of video games, the way most people will see performance problems is in the latency of their UI interactions. You press a button and want to see the result as fast as possible. In other words, the user’s entire perception of your program’s performance falls into that 0.1%.
Performance for performance sake is an interesting and appealing challenge to us engineers. I was writing C code in the 90s and I miss being that close to the hardware, trying to spare every clock cycle that I could while working with machines that had sparse resources.
But today I'm building SaaS products for millions of simultaneous active users. When customers complain about performance it is often not what us engineers think of as "performance." They're NOT saying things like "Your app is eating all memory on my phone" or "the rendering of this table looks choppy." It's usually issues related to server-side replication lag causing data inconsistencies or in some cases network timeouts due to slow responding services.
The point is the age old advice that we were giving aspiring game programmers back in the 90s:
Figure out and understand your priorities.
The famous inverse square root function in the Quake III Arena source code is a great example. If memory serves me, they needed this calculation as part of their particle physics engine. The problem is that calculating inverse square roots precisely is very expensive, especially at the scale they were required to. So they exploited how 32-bit floating point numbers are represented in binary in order to do a fast, good enough approximation. This is a good example of a targeted, purposeful optimization.
Back in the 90s we were obsessed over getting the most out of our hardware, especially when coding games. So we picked up all sorts of performance hacks and optimizations and learned how to code in assembly so that we could get even closer to the bare metal if we needed to. The result was impossible to understand and maintain code and so experienced engineers taught us young'uns:
Write clean code first, then profile to understand what your bottlenecks are, then to make TARGETED optimizations aimed at solving performance issues in order of priority.
That priority always being driven by user experience and/or scalability requirements.
Anything else is premature optimization. You're speculating about where your performance bottlenecks are, and you're throwing out maintainable code for speculative reasons; not actually knowing how much of an impact your optimizations are going to have on user experience.
Earlier quoted context omitted.
[flagged]
[flagged]