Clean Code is True Shit. The real gem is code whatever you understand & like, without any limitations.

i'm not really against OOP but i find that it is really hard to actually get it right without starting over. to setup a clean and extensible class and inheritance structure, you need to be completely aware of what classes you actually need and what they should be able to do. i'm currently learning the Godot game engine and it's base classes inheritance structure is one of the cleanest i know. the thing is that it only works because it is a mix of inheritance and composition. it has a clear separation between node classes and Resource classes. resources are components that can be added to a node. a shape would be a resource that you can add to a node to display it. i find that what most people think OOP is, is a purely on inheritance reliend data structure with no composition or config files. so if they try to explain OOP they end up with the car model where they go "car" -> "Jeep" -> "Motor" or something similar and then fail to add tires or the rest of the car to the structure. they completely miss that compositon is a thing in OOP too. "clean code" shouldn't be about "optimised code" and or the speed of the code but about how tightly knotted the spaghettie lines are. (i find most abstracted code ends up more tightly knotted than what most see as bad spaghettie code) the godot engines inheritance is max 7 deep starting with the abstract "Object" class going "Object" -> "RefCounted" -> "Resource" -> "InputEvent" -> "InputEventFromWindow" -> "InputEventWithModifiers" -> "InputEventMouse" -> "InputEventMouseMotion" i know people who start with 7 deep inheritance before they even get to the class they want to actually write instead of writing the class and then look where in the inheritance tree it makes sense. it is so easy to "clean up" code by removing layers on layers of abstraction that have little use or even should be composed in instead to make it easily changable. "Vehicle" -> "car" + "Specs" + "GroundMovementHandler" -> "Plane" + "Specs" + "GroundMovementHandler" + "AirMovementHandler" and so on. (+ means composed in) clean code is code that can be changed without 20+ other scripts and functions breaking because of a single line. it means to make code only as abstract as it actually needs to be to do it's job. there is no need for 5+ layers of abstraction for an UI based clicker game but some still try to do that and cry about OOP being painful to do.

That video you responded to made me angry in a way few videos do. There's things I agree with but it's just the definition of premature optimization. Write the simplest solution first, the one that's easy to understand and edit. When the time comes to add more features (ie add more shapes) or when performance becomes an issue, then redesign the architecture to fit your new needs. Clean code to me just means "Simple, good code" that does exactly what it needs, not more, not less. It's impossible to know the final needs and design of the program but you'll find out as you go. Premature abstractions and hyperoptimization are both unnecessary unless the design calls for it, but don't waste your time doing either of these things right off the bat. Optimize when needed, abstract when needed. That's clean code

So what is clean code? By what you mention it is just simple code?

Great presentation. Some great food for thought. I personally sometimes spend too much time trying to build the most "clean" and expandable code for future cases that will probably never come. I'm definitely taking some of your points into consideration next time!

As a professional low level performance hardware graphics programmer, I am entirely opposed to you and my experience always proved Casey right to the extent his opinion would differ with yours. You are NOT considering all factors. Maintainability, extensibility, programmer productivity, and mental appreciation of a feeling of optimum quality are all real factors optimized by DOD and pessimized by OOP.

Excuses for suboptimal quality.

I loved the chainsaw argument pretty funny, but if 'clean code' doesn't provide any benefits why learn that toxic pattern at all my point is why not just make your c code easier, it doesn't need to be in python to be easy in the end you just interface and call functions

depends on what you mean by clean code. does clean code mean does it mean the abstract mental model implemented in code, or the organization of data in your mind. or the actual written code? clean code is just for managers who cant read code or for jr programmers that needs a bit of time to dig deep. i do hack codes to circumvent programming language capabilities and its compiler's limitation unless its open source.

A problem with OOP is that both logic and data get scattered all over the place. I'm not sure that by splitting everything into tiny little bits of files, classes, functions and data you really gain in maintainabily in the long run. As to Caseys example: An array of triples (shape,w,h) together with a definition what shape, w, and h are *is* much simpler and much simpler to work with than all these classes. Suppose, for some reason, you need to make a copy of you data structure. It will be one line of code for the array of values, whereas you will need to add a virtual clone method to every class in the OOP case. Conjecture: OOP code almost always gets pretty complex pretty soon, as you do not see the entire picture anymore.

I enjoyed this push back of a push back with regard to our current day's programing environment and coder attitudes. One thing that I've always done and still do even more so now that I'm in my 40's is to hear out as many perspectives as I can, take in what's valuable, maybe try it in a small experimental project, then discard what isn't all while fighting the temptation to absorb any single philosophy or slip into a rigid adherence to a particular programming style or language. Another thing I've decided lately too is to branch out from my comfort zone of languages like VB and C/C++ into something like F# but with F# in particular I still can't wrap my mind around doing everything completely functional. I say all that to say in terms of this topic, while going through my journey the other day I watched an interesting video where the programmer made an argument that what we understand or commonly perceive as OOP today is more of a watered down derivative than what it's original intent and application was and makes me want to understand more about it from that angle. He used Squeak and Smalltalk as an example of what OOP originally meant so now I'm interested in digging a bit deeper into that or seeing what's the difference between classic OOP and modern OOP. Maybe some of the reservations or concerns I've had against OOP were misguided and it's really against the modern way all along where if I went back to learn the concept in it's original intent and implementation there's value in there I didn't know about. 😃

great video, found it through the article which was also very good

2-second loop bodies, lol. But I have to disagree with "It's fine to use OOP". It makes any future optimisations basically impossible. Blackboxing your control flow will kill any kind of free performance that you'd have gotten by not black-boxing it. Blackboxing is useful if you want to mentally compartmentalise concepts to reason about them in terms of common properties they have. But in a program, you're not reasoning about things on an abstract level. You're doing concrete workloads on concrete objects. As soon as you start using OOP, you're probably using it at every level of the program. An OOP solution requires more code to write, and has less performance ALWAYS, because the compiler cannot optimise it. So it actually takes more effort to even write it out. The only kind of effort that OOP saves is that you do not have to think much about what kinds of problems you're solving. Regarding your claim that Width, height is invalid: Casey could easily have added a flag or enum that controlled the general class of shape (branching in a switch to the correct formula, or using an additional factor and weight). That would have slowed down individual shapes a bit, but it would still make it faster than an OOP version. OOP only cares about the abstract operation you want to perform, but completely disregards memory layout, the similarities of data types, or the similarities of operations. OOP is platonic programming, and since it discards basically all concrete parts of the problem from its model, it not just prevents the compiler from having a deep understanding, but also the programmer. OOP is for intellectually lazy or disabled programmers.

As Obi-Wan once said: "Only a sith deals in absolutes." Same goes for coding😊

"Clean code contains piles of useless abstractions, is overengineered, obscures the flow of control with tiny methods and classes that each do very little" Because clean code has tools to create abstractions, however it doesn't give you an answer to the question why and when to use it, so people apply to everything if you don't limits then it doesn't have limits Clean code isn't written with good engineering vocabulary, it is written as gospel This means that if you remove 2-3 words from the gospel it has different meaning A good engineering and well written rules don't have that problem a great example is Fallacies of distributed computing - if you know them you can't misuse the rules, unlike the rules proposed by Clean code/ SOLID or other gospels on the internet

I feel that your title does not match your argument. To extend the metaphor, your argument seems to be: "use chainsaws to cut trees, and scalpels to cut surgical incisions. They both have a place, and it depends what you're trying to cut and why." Meanwhile, your title reads: "Chainsaw Cutting is Good Cutting."

Thank you for this lecture.

Nice essay, it is pleasnt to listen. Excellent job!

11:51 As you showing mobile game, you forgot about power effeciency and battery use, then Casy is still not wrong.

So use the right tool, for the right job, yup math checks out.

To optimize my code, I declare my main function as constexpr so all my code is executed at compile time and I achieve infinite performance

The name "clean code" has a lot of bad baggage that needs to be cut and proper well though out ideas and methadologies associated with it for people to forget the currently bad "clean code" and improve. Casey's video just highlighted the currently bad "clean code" with it's on the surface layer concrete, but on the lower layer very poorly defined rules and methodologies. His video on "Performance excuses debunked" is great at showcasing the reasoning of his "attack" on "clean code" and how it's more on the issue that software is doing less problem solving and more wasting time for the users and devs, so being more performance aware should improve the life of a developer and improve the final product for the user. The clean code "rules" should be associated with examples, then analysed if they are practical and performant in different environments (embedded, games, frontend/UI , server, networking, etc.) and have rules of thumb that say how you should tweak it for your environment. E.g. in games, we figured out that shallow and wide inheritance with composition is generally better than deep and narror inheritance. I would really like if you and Casey have a discussion. It would make a really good video.

Clean code is a code, where you can easily spot bugs

I think there are tradeoffs worth making, and tradeoffs that aren’t. Even with the need to support many different types of shape, it would be much more performant to use a switch on the type with static functions calls, as opposed to anything Java offers. Eventually the functions wouldn’t for in the L1 cache anymore, sure, but my personal CPU (Apple M1) has 12 MB of L2 cache, which can fit a truly staggering amount of functions before it is full. This is where languages like Rust are interesting, it has the same ergonomics as the Object Oriented code (just a straight method call on the shape) but does compile down to the static jump table, which doesn’t happen with virtual functions (and might sort of happen in Java, but only if the JVM deems your code worthy of optimisation, which should have been done at compile time instead of needlessly pausing your code)

Abstractions have a cost; more isn't better. Now instead of learning the problem I have to learn your little dsl abstraction as well. Unless it's a genuine business concept or *really* gnarly, just write the obvious thing. And even then, save the grandiose design for version 2.0 when we're positive we know what we're solving (this is a lie, you will never know) It's easier to add code than to change it. Stop trying to accommodate the future; you're actually making it harder.

If you just focus on writing good code, with correctness, performance and simplicity in mind you'll find that you use the appropriate programming paradigm at the appropriate time. Ultimately the problem space is king.

I found this to be very insightful. It's very easy to fall into the mind set that clean code means boiler plate - bad performance code. But in reality, OOP, Functional, POP, DOD, etc. They're all tools to solve problems we might face in our programming journey. Refusing to learn and understand one of these would mean (Utilising your own analogy) refusing to use chainsaws due to its failure in a specific task. The main points I got out of this is to look beyond the code and understand what is really happening behind the scenes. Understand why your code isn't running well and instead choose the best tool for the job. Keep up the great work with these insightful videos!

If good code was easy...

11:45 - spending time to optimize it isn't worth it... but is spending time making this abstraction worth the time then? Obviously in candy crush there are no special shapes, so what's the point exactly of spending more time crafting obfuscated code + making it slower? Maybe im not clever enough for oop and solid but it never made sense to me how this is "clean". Caseys code took me a few seconds to grok, the other code requires up to date documentation with arrows pointing all over the place, especially if it gets more complicated over time.

After watching that video, my only thought is: When did Clean Code was promoted as a way to improve performance? If not, what's the point to make such a claim ? Unless when someone wants to promoting his own course?

There is an approach that was for some reason overlooked by most in the PLT community: languages with a well defined separation between logic and performance semantics. What our manual optimisations are? Just applications of certain rules and strategies - e.g., scramble and de-scramble data around some heavy computation (turn a bitmap into a z-curve, etc.), turn an array of structures into a structure of arrays, fuse loops, and so on. These optimisations make code unreadable and unmaintainable. So the more reasonable approach is to write a readable high-level code, and then annotate it with optimisation hints that must be automatically applied. You really don't need to sacrifice performance for readability while you can have both.

13:19 That chainsaw comparison is quite good, however I think it’s kinda funny how the chainsaw was originally invented for use during complicated childbirth situations.

I love how you use the analogy of a chainsaw for the OOP version instead of for the AVX vectorized version :D But it's true, you don't do the yard work with your scalpel. It's also true that a chainsaw can cut someone open real fast!

Finally someone who adds substance and nuance to the polemic discussion of capital C clean code. The double logarithmic plot at 19:20 is pure gold and a great view of optimization as a tradeoff. Also, is 22:11 why it's called C++? 🤔🤯

Awesome video. I'd never heard of the term thought terminating cliche. I'll use that to defend myself against lazy thinking. I like how you we quantified when each approach makes sense. So much of programming feels like it's based on vibes, and it's good to remember that we can base our coding style on the problem at hand.

Good video. I personally don't really care about the topic because everyone has a different definition about clean or dirty code. I just want the code. 😅

I generally agree with this assessment (talking about loop bodies is particularly helpful), but you're running into the same problem Casey did when this went viral. The reason people don't like clean code as a book is that you have a bunch of developers using it as a reason to make an abstraction for shapes when they only have one shape type in code. People don't like having to extend code that's prematurely optimized for essentially the same reason they don't like something that's prematurely abstracted: both are very difficult refactors and probably mean changing a fundamental data structure or a shared function call. The advice from both Casey and Bob are the same here: start very simple, and when you see shared values, you put them into a data structure. The difference is primarily on how they handle procedures, and how early they reach for an abstraction. Ask yourself how easy it would be to extend either of these. Since the code hasn't actually gotten the avx implementation yet, it's actually not that hard to make another struct or union for other shapes, and to add appropriate methods to handle that data. The version with inheritance wants to own all possible shapes in its parent class, and so if you run into a shape that doesn't fit the parent, you run afoul of liskov and all your efforts have to be rethought. If you find you have a need to optimize, the work You've done up to the present is also a barrier rather than a help. Clean code as a concept is a bit vague but like porn, you know it when you see it. Unlike porn, no one's going to complain if they see it on a monitor in the office. The book is more an artifact of the Java era, but can still hold some value to developers who know when they're being too proscriptive. The trouble is that since the rise of OOP and clean code, devs increasingly don't have access to this info. They don't know what Uncle Bob assumed they do - that steps like polymorphism over branching can make complex problems easier to read, but they always come with a sizeable overhead, and so shouldn't be taken until very late in a project when you need extreme measures to keep things manageable. I'd generally prefer working with Casey's code over Bob's because i think its simplicity makes it easier to work with, but their process that it starts out exactly the same: do the simplest thing that accomplishes the goal. They then both eliminate redundant code through data structures and better procedures. The difference is the goal they're working towards, and my experience is that close adherence to OOP and the Coean Code book simply isn't readable or maintainable in larger projects because of the code winds up being loosely coupled to a lot of things, and too generic to offer much of a guide to its purpose if the original name isn't relevant any more.

👏

Good article. Thank you for narrating it

Awesome video, keep up the great work! :)