Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A group of developers and I recently started a book club, and our first book of choice is Clean Code by Robert C. Martin. It is a great book on software craftsmanship and I would highly recommend it.

I invite other developers to share their definitions of clean code.

share|improve this question

closed as not constructive by ChrisF Jan 28 '12 at 14:34

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

Excellent choice! –  Dima Oct 21 '10 at 21:48

15 Answers 15

I think my best definition of Clean Code would be:

Code that I can skim, and immediately understand it's purpose and how it works.

That seems simple enough, but alot of goes into fulfilling that goal, such as:

  • Good naming of types, methods, and locals.
  • Avoiding "clever tricks".
  • Not putting too much in one statement / line.
  • Adhering to a shared coding style, if on a project with more than one developer.
share|improve this answer
Max 80 characters long lines :) –  mhitza Oct 22 '10 at 20:37
Enough blank lines to visually mark code sections, and nice alignment that makes it easy to pinpoint when there is someting odd. –  Miguel Veloso Oct 24 '10 at 6:16

Clean Code:

The code which doesn't make me want to kill the author.

I can accept different coding styles, but if I can't read the damn thing, I will hate the damned author.

Update: Sometimes, it is possible to discover that I am the damned author :)

share|improve this answer
+1 for 'being the damned author'. Always write code that can be maintained by people who don't know what you were thinking when you wrote it, because most often that person is you. –  GSto Oct 21 '10 at 18:42
Hah, that's a good way of putting it! If you've never [facepalm]ed yourself while reading your own code, you're stagnating! –  dr Hannibal Lecter Oct 21 '10 at 19:27
I thought this was a rather amusing answer until I saw who wrote it. O.o –  gablin Oct 22 '10 at 7:29
@gablin: I try to be consistent whenever I can.. ;) –  dr Hannibal Lecter Oct 22 '10 at 9:06
@dr Hannibal Lecter: You know, this takes the expression Write code as if the guy who will maintain it is a psychopatic maniac who knows where you live to a whole new level. ^^ –  gablin Oct 22 '10 at 9:10
  • Nothing is in the code (including comments) that is not needed (so if the code is not needed, then delete it, don't comment it out).
  • Every line should serve a clear purpose, and be as concise as possible without sacrificing readability (no need to obfuscate your code, but also no need to be more verbose than is needed).
  • Consistency, both in naming convention and coding style.
share|improve this answer

Somewhere between

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery


There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. -- Tony Hoare

you get clean code.

share|improve this answer
+1: Quotes thumbtacked. –  Allon Guralnek Feb 8 '11 at 8:02

Clean <=> Simple.

share|improve this answer
  • Consistent code: it doesn't look like more than two people have written.
  • Naming: sensible names for functions and variables.
  • Good ordering: head files should be sorted in a consistent way. Functions should be sorted.
  • Comment: consistent with code. If quirky things have to be done, they should be documented.
  • No warnings: for compiled language, no warning should be given.
  • Well componentized: things are modulized correctly.
share|improve this answer
Quirky is a sign of unclean. –  DexterW Oct 21 '10 at 20:49
+1 for sensible naming. float dot = dot(vectorA, vectorB); ftl. –  tenpn Feb 8 '11 at 16:56

I haven't read the book you suggest but my idea of clean code is as follows...

  • Similar format (look and feel) throughout
  • Parameter naming is consistent and makes since
  • Parameters are EXPLICIT and STRICT in use
  • Comments that are concise/relevant and not stories (I have seen some code whose comments read like a book when there are only a handful of lines of code)
  • Simplicity is best when possible
  • Complexity should be used only when required and documented appropriately - Complexity should not be used to make yourself (if you are the developer) the knowledge silo of the system in an attempt to make yourself a "required" asset of the company in order to continue support - which I have seen done before
share|improve this answer

"clean code" is one of those marketing-phrases that puts a dent in my ability to take anything the person says afterward without a serious grain of salt.

@grokus about has it right.

share|improve this answer
You are a brave, brave man. Only s/clean code/<any buzzword> . –  dsimcha Oct 21 '10 at 21:49
  • Keeping it as concise and as small as possible. (KISS)
  • Logical separation of functionality.
  • Enough layers of abstraction to keep each component manageable.
  • Consistent coding style.
  • Intuitively named object/methods/variables.
  • DRY - Don't repeat your self.
  • Well documented.
  • Unit and regression tests.
  • Avoid use of globals.
share|improve this answer

For me writing good code always seems to come down to this:

The minimum amount of clearly understandable code needed to solve a problem with as few dependencies as practically possible

Possible addition: "with adequate performance"

share|improve this answer

I feel clean code is just three things, in order of importance: (big statement, I know :))

  1. Reuseable (Don't Repeat Yourself - DRY)
  2. Readable
  3. Performant

Readable code can be subdivided into, again in order of importance:

  1. Understandable (Seperation of Concerns - SoC, high cohesion, loose coupling, comments)
  2. Readability by convention.
  3. Easy to read syntax/formatting/naming


I believe reusing code (and thus making code reuseable) is a severely underestimated principle. Most people understand the benefits of it, but don't always apply it. To sum up why I feel reuseable code is the most important in one sentence: "Reuseable code can be achieved by making code readable and performant."

To explain why performance is placed last, I quote Bill Harlan: "It is easier to optimize correct code than to correct optimized code."

I feel code should be easy to read, but being able to understand it easily is more important. You always have a learning process to go through when using a new language or API. Some introduced keywords might be vague at first, but very concise once you understand them by reading documentation (comments).


Warning, my following opinion of the Clean Code book could be somewhat of a rant, but I'll try to stay constructive. :)

I finished reading Clean Code recently, and found it disappointing in some (but definitly not all) areas. Originally, I wanted to buy The Pragmatic Programmer, which wasn't available, but I figured Clean Code to be similar.

The problem I see with it, is it is written too much from the perspective of Test Driven Development. It explains concrete fixed steps how to refactor code, and somewhere along I feel the intent is lost, or ill-explained. To compare with the priorities I stated earlier, Uncle Bob places 'Testable' on 1, whereas I would probably place it at 3.

To give a concrete example, in his book he specifies the following sample as clean code:

private String getPageNameOrDefault(Request request, String defaultPageName)
    String pageName = request.getResource();
    if (StringUtil.isBlank(pageName))
        pageName = defaultPageName;

    return pageName;

Where I would prefer the following:

String pageName = request.getResource();
pageName = StringUtil.isBlank(pageName) ? defaultPageName : pageName;

This is a concrete example why I find reuseability to be more important than readability. The ternary operator isn't readable per se, but once you understand it, it is definitly powerful.

If you like to read more about this rant (and others), I wrote a blog post about it.

share|improve this answer

I'd add "minimal edge cases" to the things listed above.

share|improve this answer

Clean Code:

Code that is written in the Clean programming language.

share|improve this answer
nice joke but not answering the question –  Peter Kofler Feb 11 '13 at 20:13

For me clean code is:

  • Code which is short enough: if a code is to be read, the shorter the better.

  • COMMENTS. Even tutorials I read lack comments, WHAT THE HELL ? Even SHORT comments HELPS a lot.

  • Function names, class names etc are coherent and the semantic is correct. English is by far my preferred language I write my code in. Comments can be in my language, but I cannot bear code that mix several spoken languages.

  • Useless spacings ( like that ) ; or not enough like*(this,0+5/8);

  • Lines larger that 90 characters. 80 chars is the standard, so think 90 is okay, but larger is BAD.

  • Too much #ifdef

  • Performance bottlenecks and other careless coding: I like when a solution is simple, but I hate when someone use strings for everything, and other stuff I can't remember. CPU cycles are electricity, you better save some, at least a little.

  • Implementing features that have very little change to being used. K.I.S.S Damn it ! Programming is already complicated enough !

share|improve this answer

There is an initiative clean-code-developer (In German language only) that tries to find and document principles for good programming.

They define a value system consisting of:

 - Evolvability
 - Correctness
 - Production Efficiency
 - Reflection
 - Principles and Practices

I don't know if there is an English version of that page.

Here is the Google translation of the page.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.