I felt the same when reading that book, and I never finished it because following the rules he suggested produced horrible code.

If memory serves, he also suggested that the ideal if statement only had one line inside, and you should move multiple lines into a function to achieve this.

I once had to work on a codebase that seemed like it had followed his style, and it was an awful experience. There were hundreds of tiny functions (most only used once) and even with an IDE it was a chore to follow the logic. Best case the compiler removed most of this "clean" code and the runtime wasn't spending most of its time managing the stack like a developer had to do.

There's a piece of code in our hobby game project that I've written after attending classes in college about how to write clean and SOLID code. It's the most overengineered piece of shit I've ever written. I'm not saying it's the fault of the lectures, of course it's on me being a little bit over zealous, but it does check all the boxes - It's a simple "show selectable list of stuff", follows MVC, it's extensible without rewriting to adittional data-types and formats, extensible view that can show any part of data you need, generic, and in general it could be used anywhere we need, for any kind of data.

There's only one place where we need and use such list in our game.

I needed to rewrite a part of it, since the UI changed drastically, to not need this kind of list, while also adding events into the process. I haven't seen the code for almost 4 years, and it's attrocious. Super hard to understand what's going on, since it's too generic, interfaces and classes all over the place, and while it probably would be possible to rewrite the views for the new features we need, it's just so complex that I don't have the mental capacity to again figure out how it was supposed to work and properly wire it up again.

I'm not saying it's fault of the classes, or SOLID. It's entirely my fault, because the classes inspired and hyped me with ideas about what a clean code should look like, that I didn't stop and think whether it's really needed here, and went over-the-top and overengineered the solution. That's what I'd say is the danger of such Clean Code books and classes - it's easy to feel clever for making something that passes SOLID to the letter, but extensibility usually comes at a complexity, and it's super important to stop and think - do I really need it?

I feel like it’s wrong to idolize anything in the same way that it’s wrong to throw out many things (there are some clear exceptions usually in the realm of intolerance but that’s unrelated to this). Clean Code, like every other pattern in software development, has some good things and some bad things. As introduction to the uninitiated, it has many good things that can be built on later. But, like Gang of Four, it is not the only pattern we apply in our craft and, like Agile, blind devotion, turning a pattern into a prescription, to Clean Code is going to lead to a lot of shit code.

Cognitive load helps us understand this problem a lot better. As a junior with no clue how to write production code, is Clean Code going to provide with a decent framework I can quickly learn to start learning my craft, should I throw it out completely because parts are bad, or should I read both Clean Code and all its criticism before I write a single line? The latter two options increase a junior’s extraneous cognitive load, further reducing the already slim amount of power they can devote to germane cognitive load because their levels of intrinsic are very high by the definition of being a junior.

Put a little bit differently, perfection (alternatively scalable, maintainable, shipped code) comes from learning a lot of flawed things and adapting those patterns to meet the needs. I am going to give my juniors flawed resources to learn from to then pick and choose when I improve those flaws. A junior has to understand the limitations of Clean Code and its failures to really understand why the author is correct here. That’s more cognitive science; we learn best when we are forming new connections with information we already know (eg failing regularly). We learn worse when someone just shows us something and we follow it blindly (having someone solve your problem instead of failing the problem a few times before getting help).

I’m gonna be super hand-wavy with citations here because this a soapbox for me. The Programmer’s Brain by Felienne Hermans does a good job of pulling together lots of relevant work (part 2 IIRC). I was first introduced to cognitive load with Team Topologies and have since gone off reading of bunch of different things in pedagogy and learning theory.

It makes me sad to see people upvote this.

Robert Martin's "Clean Code" is an incredibly useful book which helps write code that Fits In Your Head, and, so far, is the closest to making your code look like instructions for an AI instead of random incantations directed at an elder being.

The principle that the author of this article argues against seems to be the very principle which helps abstract away the logic which is not necessary to understand the method.

public void calculateCommissions() {
  calculateDefaultCommissions();
  if(hasExtraCommissions()) {
    calculateExtraCommissions();
  } 
} 

Tells me all I need to know about what the method does - it calculates default commissions, and, if there are extra commissions, it calculates those, too. It doesn't matter if there's 30 private methods inside the class because I don't read the whole class top to bottom.

Instead, I may be interested in how exactly the extra commissions are calculated, in which case I will go one level down, to the calculateExtraCommissions() method.

From a decade of experience I can say that applying clean code principles results in code which is easier to work with and more robust.

Edit:

To be clear, I am not condoning the use of global state that is present in some examples in the book, or even speaking of the objective quality of some of the examples. However, the author of the article is throwing a very valuable baby with the bathwater, as the actual advice given in the book is great.

I suppose that is par for the course, though, as the aforementioned author seems to disagree with the usefulness of TDD, claiming it's not always possible...

IMO it would be best to present code that fits in a single file to people on the net and refactor it to their liking while keeping the same functionality, then let others rate the style and pick a few characteristics. Then the code can be ranked by the different characteristics to obtain the top 5 or so "cleanest" coding styles.

I feel it's worth doing an entire study instead of relying on what one dude says is clean code. Let the people speak.

Anti Commercial-AI license