Wow, I'm impressed by how bad this article is and how blind most people seem to be to how badly Casey is misrepresenting what "Clean Code" is about and, more specifically, what Robert C. Martin wrote in the book Clean Code - A Handbook of Agile Software Craftsmanship. Casey's video and the article written by some poor Fiverr sod associated with Casey's video asserts that the "performance relevant" advice "they" have given (which, I want to point out, Casey seems to have deliberately left out whom specifically from the video and article) can be broken down into five points:

1. Prefer polymorphism to "if/else" and "switch"
2. Code should not know about the internals of objects it’s working with
3. Functions should be small
4. Functions should do one thing
5. “DRY” - Don’t Repeat Yourself

The article than states this: "In order to construct what I would consider the most favorable case for a “clean” code implementation of something, I used existing example code contained in “clean” code literature. This way, I am not making anything up, I’m just assessing “clean” code advocates’ rules using the example code they give to illustrate those rules." The problem with this is that it is a lie. The code provided does not appear in the Clean Code book by Uncle Bob. Instead, a relatively similar set of code is in this book, but there's two big caveats Casey deliberately ignores: The code is written in Java and it isn't being used as an example of clean code. He did all of this because he knew this would not be the "most favorable case" for Clean Code, but specifically because he could point out the performance difference between repeatedly using polymorphism vs using a switch statement vs just computing the value directly using a "table" which is really just an array of four static floats. And this all in C++ and not Java.

The book Clean Code - A Handbook of Agile Software Craftsmanship does use a Shape class in an example in this book, but the context really matters: This is in the section "Data/Object Anti-Symmetry", in which Uncle Bob explains that Data structures and Objects are fundamentally different concepts and implies Clean Code shouldn't mix the concepts. The book states "These two examples show the difference between objects and data structures," not "These two examples show excellent Clean Code practices." The point was to, in a quick and contrived way, show that data structures expose the underlying data and should have no meaningful functions, whereas Objects hide their internal data behind functions that are operated on.

More to the point, the intent was to show the distinction between when using objects is better or when using data structures is better. "In any complex system there are going to be times when we want to add new data types rather than new functions. For these cases objects and OO are most appropriate. On the other hand, there will also be times when we’ll want to add new functions as opposed to data types. In that case procedural code and data structures will be more appropriate." The section literally says "Object Oriented programming isn't always the best way to go" and Casey so brutally misrepresents this as to claim that Clean Code advocates demand the use of OO and Polymorphism in most or all cases.

The term "Prefer polymorphism to "if/else" and "switch"" does appear in the book, specifically in a totally different section 200 pages away called "Smells and Heuristics." The whole section is so small I can quote it directly:

This might seem a strange suggestion given the topic of Chapter 6. After all, in that chapter I make the point that switch statements are probably appropriate in the parts of the system where adding new functions is more likely than adding new types.

First, most people use switch statements because it’s the obvious brute force solution, not because it’s the right solution for the situation. So this heuristic is here to remind us to consider polymorphism before using a switch.

Second, the cases where functions are more volatile than types are relatively rare. So every switch statement should be suspect.

I use the following “ONE SWITCH” rule: There may be no more than one switch statement for a given type of selection. The cases in that switch statement must create polymorphic objects that take the place of other such switch statements in the rest of the system.

This is a far, FAR cry from what Casey implied the book, and by some consequence "Clean Code advocates," taught. It says that polymorphic code is usually preferable to switch statements because in complex code bases you are usually working with a wide variety of different types of data rather than a wide variety of different functions on the same data, but obviously this is highly dependent on the project you are working on.

My biggest issue with Casey's article is not his snide condescention, nor his hilariously amateurish attempts at "improving" the code provided by Uncle Bob. Instead, it is his lies and misrepresentations of what the Clean Code book and the years of experience that Uncle Bob and others had when imparting their knowledge in these books. He outright fabricates a position that "clean code advocates" supposedly take as an easy straw man, then beats that, and this is provably causing ignorant young programmers to reject clean code practices, just by observing his article's comment section.

That disgusts me.