Clean Code: Second Edition Critique - Clean Code - Critical Analysis

Clean Code Critique: Why Much of 'Clean Code' Aged Poorly (+ Better Alternatives)

Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Auto

Light

Rust

Coal

Navy

Ayu

Clean Code - Critical Analysis

Review of "Clean Code" Second Edition

Reddit · 219 comments

Hacker News · 6 comments

This is true! Clean Code’s second edition is pretty much the same: same tiny-functions style, the same old OOP habit of mixing data and behavior into choppy class designs, and the same blind spots.

I wrote a critique of Clean Code's first edition and was curious how much of it would become obsolete.<br>After reading it, the answer is: "not much, if anything"

It is a different book in some ways:

The first edition was focused, concise and highly opinionated. You could disagree with 80% of it and still appreciate it as a clear, coherent message about one particular style of programming.

The second edition is less focused. It’s an amalgamation of Martin’s work - a collage of<br>Clean Code, The Clean Coder, Clean Architecture, We Programmers, and SOLID material.

It’s also a noticeably thicker book - full of digressions, rants, and good old rambling.

But the code part has not really changed. This review focuses on "Part 1: Code".

...

Here's a good example of the new format:

In Chapter 10 - "One Thing" - he addresses critiques of his style of tiny functions:

Over the years, this particular recommendation, from the first edition of this book, has been the most controversial. But why?<br>There are a lot of reasons.

People are afraid that if they follow this rule, they will drown beneath a sea of tiny little functions.

People are afraid that following this rule will obscure the intent of a function because they won't be able to see it all in<br>one place.

People worry that the performance penalty of calling all those tiny little functions will cause their applications to run<br>like molasses in the wintertime.

People think they're going to have to be bouncing around, from function to function, in order to understand anything.

People are concerned that the resulting functions will be too entangled to understand in isolation.

Let's address these one at a time.

Drowning

Long ago our languages were very primitive. The first version of Fortran, for example, allowed you to write one function. And it<br>wasn't called a function. It was just called a program. There were no modules, no functions, and no subroutines. As I said, it<br>was primitive.

COBOL wasn't much better. You could jump around from one paragraph to the next using a goto statement; but the idea of functions<br>that you could call with arguments was still a decade in the future.

When Algol, and later, C, came along, the idea of functions burst upon us like a wave. Suddenly we could create modules that<br>could be individually compiled. Modular programming became all the rage.

But as the years went by, and our programs got larger and larger, we began to realize that functions weren't enough. Our names<br>started to collide. We were having trouble keeping them unique. And we really didn't like the idea of prefixing every name with<br>the name of its module. I mean, nobody likes io_files_open as a function name.

So we added classes and namespaces to our languages. These gave us lovely little cubbyholes that had names into which we<br>could place our functions and our variables. Moreover, these namespaces and classes quickly became hierarchical. We could have<br>functions within namespaces that were within yet other namespaces.

He keeps going, but you can see that:

Points 1, 2, and 4 are essentially the same concern.

Folksy phrasing like “run like molasses in the wintertime” doesn’t clarify anything.

Instead of addressing the core critique, he detours into a thin language-history lesson.

This is the style of the second edition.

What has somewhat improved is the Java code: most examples in the first edition were abysmally bad, and while the second edition is better, it still leaves much to be desired.

The second edition has examples in other languages. But Martin writes Python and Go as if they were Java with disclaimers that he doesn’t really know them:

"It’s been a long time since I’ve written any Python, so bear with me."

"I apologize - I am not an accomplished Golang programmer"

Why does he use them?<br>I guess to prove that the ideas aren’t Java-specific and apply across languages. And they might be - if you write Java in Python.<br>Do they apply if you write Python in Python? That’s left as an exercise for the reader.

Over the years Martin has definitely heard the critique of his original book, and he has participated in debates around it (with Casey Muratori about performance,<br>and with John Ousterhout about style and design).

I don't believe Martin internalized the critique or revised any of his...