Interesting read. I read a companion book (or is it wholly unrelated?) called Clean Code for Python and I learned a whole lot! That book improved my Python more than anything else, honestly. That being said, I agree with the critique that obsessively committing to DRY is throwing the baby out with the bathwater.

I don't like clean code, and like the author I find the things presented in Clean Code to just make incredibly inscrutable code. The worst code bases I have seen have been the ones with no code plans at all, and the ones that use Clean Code and Gang of Four like a bible, both are equally mazes of spaghetti. Clean Code I really just don't agree with, and I think this author lays it out well. Special design patterns and tons of polymorphism usually end up creating multiples of complexity in the effort to reduce DRY at any cost (and often are abstractions that are only ever used one or two times anyways).

Ultimately I think the single most important rule for clean code is: skinny controller, fat model. If you are doing batch data, then this applies still I think. You should have all of the logic you can in the model, avoid data objects. And the code paths that alter things should be as thin as possible. I honestly think it is better to have a 5k line model if it avoids more.

The most unlcean code I have seen usually falls into the abstracted out processes in financial instutitons where they follow Clean Code advice and everything are a bunch of functions passing around some big fat objects full of getters and setters, and changing any functionality means adding changes somewhere in the process to check state and alter the state, which leads to loops and if statements everywhere to see which account type it is at each point etc.

But in OOP programming its supposed to be objects sending messages to each other. Every object should know everything about itself, which is what a fat model demands. Any more abstraction than that seems to get in the way.

The popular OOP seems to be exactly the opposite of what OOP was meant to be. If you get into the original intentions, it honestly starts to sound more like FP.

Absolutely agree.

Popular OOP passes Structs around (they just call them records or POJOs or whatever) through a bunch of "classes" that do x. But you could rewrite the code from Java or C# or C++ into C or Cobol and it basically is the same. Its just imperative code with classes as a nice way of getting rid of globals.

The side effects example is exactly where I put down the book. I briefly questioned whether the book is supposed to be satire.