What does Clean Code mean to you? [closed]

Question

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.

Answer 1

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.

Answer 2

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 :)

Answer 3

• 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.

Answer 4

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

and

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.

Answer 5

Clean <=> Simple.

Answer 6

• 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.

Answer 7

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

Answer 8

"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.

Answer 9

• 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.

Answer 10

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"

Answer 11

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

Motivation:

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).

Rant:

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.

Answer 12

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

Answer 13

Clean Code:

Code that is written in the Clean programming language.

Answer 14

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 !

Answer 15

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.