Thursday, October 30, 2014

CC - What is Clean Code?

Ref: Clean Code by Robert C. Martin

Bjarne Stroustrup, 

inventor of C++and author of The C++ Programming 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.
  • Elegant, Pleasing to read. Reading it should make you smile the way a well-crafted music box or well-designed car would. Straightforward, hard for bugs to hide.
  • Efficient, this should not surprise us coming from the inventor of C++
  • Does one thing well, Clean Code is focused.

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 designer’s intent but rather is full of crisp abstractions and straightforward lines of control.

  • Readable like a well-written prose
  • It should contain only what is necessary.

“Big” Dave Thomas, 

founder of OTI, godfather of the Eclipse strategy


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.

  • Readable as makes easy other people can enhance it.
  • Dave ties cleanliness to tests. He is right, Code without test is not clean.
  • Minimal, Smaller is Better. 3S Rule: Small-Simple-Safe
  • Literate, in a form as to make it readable by human 

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’re led back to where you are, sitting in appreciation of the code someone left for you—code left by someone who cares deeply about the craft.

  • One word, CARE. Michael hit it on the head. Clean code is code that has been taken care of. Someone has taken the time to keep it simple and orderly. They have paid appropriate attention to details. They have cared.

Ron Jeffries, 

author of Extreme Programming Installed and Extreme Programming Adventures in C#


• Runs all the tests;
• Contains no duplication;
• Expresses all the design ideas that are in the system;
• Minimizes the number of entities such as classes, methods, functions, and the like.

Ward Cunningham, 

inventor of Wiki,

You know you are working on 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.

  • when you read clean code you won’t be surprised at all. Indeed, you won’t even expend much effort. You will read it, and it will be pretty much what you expected. It will be obvious, simple, and compelling


 We are Authors

The @author field of a Javadoc tells us who we are. We are authors. And one thing about authors is that they have readers. Indeed, authors are responsible for communicating well with their readers. The next time you write a line of code, remember you are an author, writing for readers who will judge your effort.

The Boy Scout Rule

It’s not enough to write the code well. The code has to be kept clean over time. We’ve all seen code rot and degrade as time passes. So we must take an active role in preventing this degradation.
The Boy Scouts of America have a simple rule that we can apply to our profession.
Leave the campground cleaner than you found it.

If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot. The cleanup doesn’t have to be something big. Change one variable name for the better, break up one function that’s a little too large, eliminate one small bit of duplication, clean up one composite if statement.

No comments: