There’s No Such Thing as Clean Code

It was never intended as a definitive _thing_. I don't think anyone believes it has an exact definition. Just like good writing. There is no canonical good. Shakespeare and Hemingway are both "good" but absurdly different. But still, "clean" is a useful abstract concept for us to aim for in each context we encounter. At the end of the day, we need some kind of way of talking about "desirable" or "good" code. And I feel like 'clean' is as good as any other word.

The author lists a litany of traits that could be considered "good" things to aim for, but most of them are pretty granular, fuzzy, or superseded by others. The author says:

Words like ‘encapsulated’, ‘testable’, ‘mockable’, ‘reusable’ have meanings that we can all agree on. When we use more specific words that describe the various code traits that affect our project then we can be sure that we’re all on the same page.

Unfortunately, however, we're never really on the same page. Even these more precise terms are very context specific and amorphous. "Testable" may mean granularly accessible, modular, mockable, idempotent, or quick to spin-up for CI, or only a subset of these. Highly dependent on testing approach too (unit, TDD, BDD, E2E...)

This is why I like thinking in terms of tenets: broad concepts that are applicable to everything but enable context-specific meaning. E.g.

  - Reliable
  - Efficient
  - Maintainable
  - Usable

With these tenets, for example, we can then *contextualize* and find the "cleanest" code for whatever particular application we're working on. If we want to break these broad tenets down further then we can, and I hold the position that this _is_ very useful:

  - Reliability: Correctness, Stability, Resilience 
  - Efficiency: Time, Space, Second-order effects (ecology etc.)
  - Maintainability: Adaptability, Familiarity 
  - Usability: Storytelling, Intuitive, Accessible

Most of these are independently VERY context-specific. Being time-efficient is about the available hardware, interfaces, UX, etc. Being accessible or usable is about WHO is going to use or access your abstractions and underlying implementation.

To achieve these tenets, there are many principles and approaches to draw on to help us find the 'clean' solution each time: E.g. The Law of Demeter (LoD), SOLID, The abstraction principle, Functional programming, etc. These exist as tools to help us get closer and closer to the unreachable (yet desirable) goal of "clean".

So, I suppose I agree with the author but only semantically. Cleanliness does not have a fixed definition, but it is still useful to talk about as a goal or absolute to aim for. A bit like all manner of other superlatives.

The author isn't arguing against the existence of "good" code or "clean" code but rather advocating for us to try to articulate what is good (or bad) about code because "clean" is vague and encompasses too many things.

In response to: > You definitely know it when you see it. the author suggests: > It’s good to build that intuition, but we can’t just stop there. We need to dig deeper beyond those feelings to understand and articulate why we think the code is good.

Writing is a great metaphor: there aren't any hard-and-fast rules and there's certainly a subjective quality to it... but also, some writing is clearly better and some writing is clearly worse. Maybe there is no such thing as "good" writing because writing can be "good" in different ways or because we can never fully define what "good" means, but that doesn't mean that all writing is equal or that "everything is a tradeoff"—and, like you said, it doesn't mean we need to deeply analyze every piece of writing to draw useful conclusions about it.

My view is that while there is definitely a subjective aspect to quality—whether in code or in writing—a larger portion is objective, just hard to formalize or quantify. Just because we can't measure something directly or because we can't all agree about it in every instance doesn't mean it's subjective. There are a lot of things we can't know exactly but that are still objective, so why not writing or code quality as well?

Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a time, at the same abstraction level. Doesn't force you to mentally juggle many balls at the same time.

The code often tells you a story, it communicates how the programmer (author) described the problem, the solutions and the trade-offs. Very similar to writing.

Maybe it is a vague term. But it is not an excuse to write "bad" code. Perhaps every team need to have a "definition of clean code" for themselves.