By Kenneth Selin

This summer I borrowed the book “Clean Code” from the office (author: Robert C. Martin).

I write this from memory, without cheating and opening the book again.

As the title suggests, it’s about how to write “clean code”, and what this is, is discussed in the beginning of the book. The rule of thumb that I liked, is that clean code looks “pretty much as you expect it”. That is, when you look at someone else’s code and it doesn’t surprise you with ugliness, it is actually clean! I have myself experienced this when I looked (just a little) an the Java SDK source code. I was like “yeah good code, nothing special to it”. But this means that it is clean.

All in all, I really liked this book, much for its great ability to inspire. An experienced developer will have heard about quite a lot of the contents, but probably not all, and together it is a very inspiring  read.

My favorite part is the discussion of 2 of the parts of the SOLID design principles, namely Single Responsibility and Open Closed Principle.

As I feel it, Single Responsibility Principle will take the design of your application very far if you are able to apply it. The rule basically says “A class (or other program entity) shall have just one responsibility, i.e. one reason to change.” The advantages of this are quite obvious: such a class will have a greater chance of being reused since it has a more clean purpose, and it will be easier to maintain, since this class has (by definition) just one reason to change, so you can’t mess anything else up, while you modify it!

The SOLID design principle I think is second best, is “Open/Closed Principle”, meaning the system shall be “open for extension but closed for modification”. If you are able to apply this, you will find that you can add classes and stuff when implementing new functionality, rather than modifying existing code. Again, there is a smaller risk you mess up the existing functionality.

The book contains numerous thoughts and tips and tricks about how to make your code cleaner, for example:

  • A function shall not do stuff on different levels of abstraction.
  • Various patters you can return to if you find your code being ugly, for example if you think exception handling takes to much focus from the reader.

A great read!