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 and objectively worse in hope it would be easier to extend later. Unfortunately we often dont know how the code will change, and in practice the code has to be significantly changed/rewritten anyway when a business requirement change appears.

IMHO optimizing for simplicity and readability has served me the best. Instead of avoiding the changes in code, it is better to write code so obvious that anyone can safely and easily change it when really needed.

And finally, performance of the program vs performance of the developer is a false dichotomy. So many times I've seen a more readable, simpler code turned out to be more efficient as well. You often can have both.

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 completely no idea why "software part of the internet" is losing their shit over those 2 guys arguing since it doesn't seem to be "deeper" than 2 random people arguing in some random comment chain.

I watched Casey's video in full and agree with all the points he made. But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic, and this isn't representative of every programming problem.

As an addendum to Casey's video, another popular technique for squeezing more performance is to invert the normal array-of-structs to a struct of arrays, as it tremendously improves SIMD/vectorization. https://en.wikipedia.org/wiki/AoS_and_SoA

For a lot of things that I work on, simply having correct, complete, working code is most of the battle. Execution performance takes a backseat to development time, data acquisition time, human analysis of the problem space and generated output, etc. So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.

Those are full of advices that seem reasonable but extremely generic and tend to be followed with religious fervour by people with limited experience resulting in an unreadable bug-ridden mess. When I think about those authors a single question comes to mind:

What have they ever built?

Reading code from popular opensource projects and evaluating the different approaches they took is way more useful than reading those books, full of regurgitated wisdom from people with minimal street creed. And yes, maybe it's time to stop calling him "uncle", it's not your uncle, he has very little to teach. Start building, stop reading.

The worst part is, AFAIK it's not even clear that the recommendations in Clean Code are better for developer productivity, insofar as they create excessive complexity.

Another thing to note is that I've observed a significant fraction of users (and developers!) seem to have a very poor perception of time. You can replace an app they were using with one that is otherwise exactly the same but introduces a whole second of delay when interacting with the UI, and they wouldn't notice unless you gave them the two versions to compare side-by-side. Of course another significant fraction does notice, which is why you often see both "this new version is horribly slow" and "works fine for me, it doesn't feel any slower" opinions.

The reason it doesn’t sit well is that, in practice, it seems like most products don’t know what needs to be fast and so developers end up making almost everything slow. Casey gives many examples but the one that sticks out most in my mind is the Visual Studio watch window (about 25 minutes into https://m.youtube.com/watch?v=GC-0tCy4P1U). The watch window lets you pin variables you’re interested in and it will show you their current values as you step through the program’s execution. Invaluable for debugging. Visual Studio’s watch window is incredibly slow, to the point that it actually has a debounce so it will stop updating when you’re stepping quickly and only update once you’ve stopped quick-stepping. This seriously impacts its usefulness! To me, the watch window seems like it’s obviously one of those modules that needs to be running in milliseconds or less - but the company and/or the developers don’t see that, and shipped it slow (and presumably clean) instead. So in my mind, “write clean except where performance matters” comes with an almost fatal caveat, something like “you won’t know where performance matters”.

Clean code / readable code / whatever you want to call it is often at odds with performance. This has been a known fact for decades. Everybody is aware of this. And for most enterprise projects it just doesn't matter. The performance analysis discovered nothing new and added nothing of value

Making a simple service? It’s in the descriptor. Just keep it simple.

Making something large that has a bunch of people working on it? Time to pull out the toolbelt.

Making something super mission critical? Use the right tools.

No approach is perfect. That’s why you use what makes most sense, mixing and matching, to put together what works best for the task at hand.

Anything else is noise and just ignore.

“Clean” code, horrible performance - https://news.ycombinator.com/item?id=34966137 - Feb 2023 (906 comments)

it's been chaffing me a lot last couple of years that it is so hard to learn about making performant code. It was nice of Julia Evans to write that very approachable strace zine [1]. I wished there was more of that kind of stuff. So I am happy Casey is doing a whole course on this stuff [2].

[1] https://wizardzines.com/zines/strace/

[2] https://www.computerenhance.com/p/performance-aware-programm...

Now I try to use OOP the least I can, I try to use the less abstractions I can and I try to make the CPU use the least number of instructions.

I am using a part procedural and part functional approach, keep data separate from functions that process the data, try to use immutable data where possible and minimize state changes.

I am trying to use a data oriented approach and I am more happier and productive than if I hade to apply clean code principles and software patterns on top of software patterns.

And thata before considering the great analysis of the examples in this book from a few years ago, that showed that they don't conform to the clean code philosophy at all.

Lucky for me, I bought this and procrastinated so long about reading it, I've since found out it's not good, so I saved some time.

Every extra year I spend in engineering, it's becoming clear that this is actually one of the only few things that mattered in the long run. I would say this is one of the best if not the best advice in programming and even in life.

If clean code doesn't follow that, ditch.

The dev productivity improvements are questionable.

So let's go do some harm!

(and that example of slow typing in a "big" paragraph is a big red cherry on top of a brown pile!)

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.

And then he goes on touting readability right after that. Bold.

Functions should do only one thing. Sure, but what does that actually /mean/? If a function calls two other functions, then surely, by definition, it's doing two things? So how much a function is doing is a question of how far you stand back when looking at it.

Also, if you follow a rule of functions having only 2-4 lines, then you're going to have a lot of functions, and tracing through code paths is going to be like peeling back layers of an onion. So that advice is just wrong.

It's not even clear that long functions are a problem. Back in the early 80's my A level computing science teacher, who had worked in industry, said that there was no real evidence to suggest that long functions are less readable.

There was a joke going around some time ago about an interviewee who was asked how big a function would be. He said "I like to be able to keep it within my head." When asked to elaborate, he said "I put my head against the screen. If the function is longer than that, then it's too long." Although facetious, I think that's actually a good idea. A function should be at most a screenful, so you can see it complete on the screen.

Recently, I wanted to customise my own gopher client. I first messed around with one written in Go, but it was too complicated to adapt for what I wanted. I switched to a C alternative, which was still a bit too complicated. I decided that I'd basically re-write the whole thing in C++, using whatever bits of functionality from the C part that I thought useful.

If there is a magic formula to writing good code, then I'd say that the less code you have the better, and try to keep code reasonably decoupled. The problem with writing applications is that there's a tendency to be promiscuous in how you use objects. So, in essence, every part of the program relies on every other part of the program. There's no separability of design. It is better to take a "library" approach to things, where each "module" doesn't know how it is going to be used. You then have co-ordinating functions which stitch this functionality together. The code you end up with should be much easier to adapt.

It's also useful not to be overambitious with your project. Someone once said that the genius of Ritchie and Thompson was being able to obtain 90% of the functionality using 10% of the code. If you think parsimoniously in that way, they'll be a lot less code to wade through when you want to modify things.

> Long ago he wrote a book entitled The Design of Everyday Things. It's well worth the read. Within those pages he stated the following rule of thumb: “If you think something is clever and sophisticated beware -- it is probably self-indulgence.”

> You also asked me "why...". To the extent that I have not answered that above, I'll simply turn the question around and point out that it is probably for the same reason that your video was solely focussed on the amplification of performance to the strident denigration of every other concern. To a performance hammer, everything looks like a nail. ;-)

Overall a very amicable and interesting read.

It’s so easy to preach high level architecture without specifics, but also so very easy to cherry-pick a specific example where generic advice doesn’t apply.

I think it’s interesting that there is an almost fundamental disconnect between “easy to understand” and “fast and efficient” …and I’m absolutely 100% with Uncle Bob that bounded contexts for complex code is the solution.

This is the approach rust takes with unsafe code and it has proved to be an extremely effective principle.

I've wrote about my observations with the same conclusion

https://trolololo.xyz/programming-discussions

>I've started thinking about it and realized that people arguing on all previously mentioned platforms tend to have various backgrounds

>Web developers, desktop developers, system programmers, cloud engineers, people working at startups, people working in corporations, beginners, experienced and known in the industry people, FP/OOP fans, self-taught, people after electrical engineering/computer science/mathematics, and a looot of more.

>So, what's the difference? I'd say context and the context is unfortunately lost in those discussions because all you see is just somebody's comment and that's it. Nickname very often doesn't tell you anything (except on forums after you spend some time there)

>And they all are right (or may if you want to argue :)), but very often that information about their respective domains is lost and the argument is around some "generic code base" or some "average project" which is different for everybody.

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.

The religious refactoring of any kind of software to its most generic and decoupled design, under the name of "cleanliness", is quite impressive. it's quite important that one of the most well known figure recognize that those designs have costs in terms of performance and are not suitable anywhere.

Nobody is arguing against comprehensible code. Caseys video is not about clean code in general, but "Clean Code" as presented e.g. in the book by Robert Martin, which contains a bunch of code I would not classify as "clean" by any metric.

> But as others pointed out, he focus on squeezing every bit of performance in the context of real-time video game logic

He doesn't, though. The "Clean Code, Horrible Performance" video is an excerpt from his course called "Performance-Aware Programming", where he explicitly says many times that the course isn't at all about "optimization", but merely being "performance aware". This isn't highlighted in the video though, so getting the full context is difficult.

I agree that "optimizing for human comprehension" is a worthy goal, but it is very hard to actually know what is easiest for humans to understand. I don't think that guidelines like "clean code" actually are particularly effective at making understandable code. My personal guideline is to prefer code which is "simple" for both humans and computers.

> So by default, I follow Knuth's advice that premature optimization is the root of all evil. I write clean code but go into Casey mode when the numbers justify it.

I hold the controversial opinion that Knuth's advice is not relevant to most modern programmers. Most modern programmers have never done the "optimization" that Knuth was referring to in 1974. Optimizing only the hotspots of your program is very relevant technique, but if you write terribly performant code everywhere, there won't be significant hotspots. Everything will be lukewarm.

I fully agree that human comprehension should be a prime objective for code. Alas, following the tenets of “Clean Code” produces anything but that.

We need our languages and compilers to give us the necessary tools to abstract away complexity without losing performance, which our current OOP languages don't really do.

Jai for example offers a special keyword, so the code is written one way (AOS) but the memory layout is converted into SOA.

https://pixeldroid.com/jailang/overview/Features/SOA/#/overv...

You have to be careful with that though. We've had a few people who'd "channel Torvalds", so to speak, by parroting his opinions with abrasive fervour. Any dissenters were treated as either thinking they knew better than him, or being ignorant of his work, or not having an appropriate appreciation for his work. And since Torvalds is very opinionated, so were they. It wasn’t exactly a fun work environment.

I’d also like to challenge the premise of the question. Being a maintainer for example is just as valid as being a “builder.” In fact, you’ll probably gleam more wisdom from being a maintainer than a builder since you are, by definition, trawling through other people’s code and maintaining it.

Look, it’s perfectly valid to consider someone’s body of work while considering their opinions. But dismissing them out of hand is wrong, in my opinion.

While I agree that reading code and learning is essential, I don’t think this line of criticism is fair.

I mean like most programmers I’d imagine their years and years of industry work isn’t public. I mean what have I ever built?

Fowler was CTO of ThoughWorks for years and afaik they do really good and deep work, their content is quality. Bob Martin had a similar track record with 8th light, and as an organization is interesting.

That said, I think lumping them together is misguided. I’ve read a lot of both. To me unky bob is can be a divisive gatekeeper who wants to be right, while mFowler is boon to the industry, literally writing the book on refactoring. He has well reasoned and measured arguments.

I mean I think while formulating your own voice is important and essential, it’s also essential to learn from others and pass down knowledge. For some reason, I think our industry sees it as a threat.

Unky bob is a divisive gatekeeper who I suppose did years of industry work? I guess?

To lump Fowler in with unky bob, I just don’t see it.

I mean Fowler I think t started thoughtworks.

Totally agree. I believe "Uncle" is a pretty ingenious piece of branding meant to paint him as an implicitly trustworthy and wise figure that I should feel endeared to. He's just a guy who has built a career out of offering his opinions on how others should do a job he's never done. Notice that his About page [0] doesn't mention a single piece of software that he's actually built.

He reminds me of a company I used to work for. It was a healthcare architecture firm that got sued so many times for their fuckups that they pivoted to being a "thought leader" in their industry. Instead of continuing to build hospitals, they focused on consulting and publishing articles with their innovative [1] ideas about how hospitals should be designed. A classic case of "those who can't do, teach".

[0] http://cleancoder.com/files/about.md

[1] I shit you not, one of their ideas was a "hover gurney" that was basically a giant quadcopter with a bed on it. It was supposed to be easier to move. Blasting germs all over the hallway with hurricane-force winds was apparently not an issue anyone thought worthy of consideration.