After participating in a project with focus on architecture, patterns and clean code I got a revelation: Clean code principles should be used in every software development project. I also started feeling that using clean code principles is not only a good tool but it’s a matter of taking pride in what you do. Who wants to deliver code that is unstructured and hard to read and understand?
During this project I also read a very good book about clean code: Clean Code – A Handbook of Agile Software Craftmanship, written by Robert C. Martin
This book starts with the basics; code formatting and using meaningful names, and continues with unit testing and concurrency.
The book is written with Java programming language in mind but the content can easily be adapted to other programming languages.
A quote from the book: “Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best”.
What are the benefits of writing clean code?
- The code is easy to read and understand (a good thing for new developers working on code where the original authors have started working for another company or are tied up in other projects)
- Unnecessary code and noise are removed
- Maintaining and extending the code is easier
- In my opinion the overall project life cycle cost will be reduced
What is consider to be clean code? I don’t think there are any correct answers to that question. A lot of books have been written on this subject and innumerable discussions have been held. I like to think of the clean code principles as a toolbox filled with tools. It’s up to you to pick the right tools for the work you are going to do. The most important is that you put on the clean code attitude when you are developing. And when you are developing and looking at code that you don’t find “clean”, why don’t you just rewrite it?
“Don’t comment bad code, rewrite it” – Brian W. Kernighan and P.J.Plaugher
I will go through some of the clean code principles that I find important and the ones’ that really don’t take much effort to take use of.
Code formatting: Your development team should agree in a code formatting style before starting the projects, this way the code formatting/layout will be the same throughout the whole project. In most of the IDEs’ out there you can define a code formatting template or use one of the already existing.
Naming: Choose the names carefully, if you can find a name that is self explaining that’s the best. This concerns classes, methods, variables etc.
DRY: Don’t repeat yourself. If you start using copy/paste a lot or you need to do the same changes several places in your code you should considering refactoring.
KISS: Keep It Simple, Stupid. Write the code as simple as possible, this will make it easier for the other developers to understand. In my opinion the best programmer is not the one solving difficult tasks with “amazing” code no one else understands but the one solving it with structured and easy to understand code. That’s skills!
The Single Responsibility Principle (SRP): A class or module should have one, and only one, reason to change. This will also lead to small classes which is a good thing. Methods should also be small and only do one thing.
Using these few simple principles is a good start for writing clean code but I would recommend you to read more about clean code principles to get the full picture. Writing clean code is a step on the road to increase code quality and reduce costs.