So… what is clean code? Let’s ask some giants!

As I’ve explained in my introductory post, I’m going to write mainly on the topic of clean coding practices.

Now, you may be wondering what is meant by “clean code”. What exactly does it mean for code to be “clean”?

Well, the answer is tricky. It’s as if you were to ask an architect what makes an architecture “good”. I guess that if we were to ask the top 20 architects in the world to answer the question: “What is good architecture?”, we’d pretty much get 20 different answers.

However, by listening to their answers, we may start to get a feel as to what the important criteria are, and also find recurrent and common themes emerging.

In the classic book on the subject I’m currently reading called Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin (called “Uncle Bob” in the industry), the author shares the answer to the question: “What is clean code?” by five of the most respected software engineers in the industry.

To help you get a feel for what clean code is, I’ve reproduced their answers below.

Bjarne Stroustrup, inventor of the C++ language:

I like my code to be elegant and efficient. The logic should be straightforward to make it hard for bugs to hide, the dependencies minimal to ease maintenance, error handling complete according to an articulated strategy, and performance close to optimal so as not to tempt people to make the code messy with unprincipled optimizations. Clean code does one thing well.

Grady Booch, author of Object-Oriented Analysis and Design with Applications:

Clean code is simple and direct. Clean code reads like well-written prose. Clean code never obscures the designers’ intent but rather is full of crisp abstractions and straightforward lines of control.

Dave Thomas, author of The Pragmatic Programmer:

Clean code can be read, and enhanced by a developer other than its original author. It has unit and acceptance tests. It has meaningful names. It provides one way rather than many ways for doing one thing. It has minimal dependencies, which are explicitly defined, and provides a clear and minimal API. Code should be literate since, depending on the language, not all necessary information can be expressed clearly in code alone.

Michael Feathers, author of Working Effectively with Legacy Code:

I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better. All of those things were thought about by the code’s author, and if you try to imagine improvements, you are led back to where you are, sitting in appreciation of the code someone left for you — code written by someone who cared deeply about the craft.

Ward Cunningham, inventor of Wiki and co-inventor of Extreme Programming:

You know you are working with clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.

So… were you able to detect the common patterns in all the answers?

Here is a clear and concise summary by Jakub Holy:

Clean code is…

– Easily accessible to others (straightforward, clear intent, good abstractions, no surprises, good names) — this is absolutely the most mentioned point

– Is made for the real-world, i.e. has a clear error-handling strategy

– The author clearly cares for the software and other developers (which implies both readability and maintainability)

– Is minimal (does one thing, has minimal dependencies)

– Is good at what it does

Now let me ask you the question: what is good code for you?

I invite you to think about it and post your answer in the comments.

As for me, I’ll also keep thinking about this question to come up with my own answer.

I’ve also planned for the coming weeks to ask this question to some developers I respect in order to share their answers with you, with my comments. So stay tuned!

Originally published at www.samuelpath.com on January 3, 2017.