Couple months ago I have been reading really interesting book: “Clean Code: A Handbook of Agile Software Craftsmanship” by Robert C. “Uncle Bob” Martin. I really enjoy reading it. I can shortly say that this is book for all programmers, who want to every day become better and better at writing code.
There is no one rule which tell us how to improve our skills. For sure on the beginning we can start from learning how to distinguish good code from bad code and what the consequences of writing bad code are.
Let’s start from very beginning, it is good to know where usually the source of messy code is… Why and when we are writing bad code:
- When we are in the rush
- When we have this filling that we don’t have time to do a good job and we are afraid to spend more time on cleaning code
- When we are tired of working on some program and wanted it to be over
- When we don’t know good principles
The worst think that we can do after each of this situation take place is to write some messy code and said that I would go back and clean it up later. We should remember that in most cases: “Later equals never” (LeBlanc’s law).
How to quickly identify bad code:
- When after one minute of looking at code you are not able to say what he actually do
- When you are not able to see whole method body on your big screen and when you need to scroll vertically or even worse – horizontally
- When you are not able to write single unit test, because of bad code architecture
- When you need to comment each line of your code (if you think that comments are needed you should rather make code more clear and understandable)
- When every small changes required understanding a lot lines of code, reviling hidden logic and modifying different places in code, what makes code growing and becoming less understandable
Code review is always a good tool to reveal those all programmers’ sins:
We should be aware of how it actually ends when team members don’t care about code. “It is really often that over the span of year or two teams which are moving very fast on the beginning can find themselves moving at snail’s pace”. As the mess building productivity of team decreasing, approaching zero.
How to write better code
I think that there is enough bad examples. Now I can focus on good code.
In book there is a lot of definitions of good code, but my favorite is written by Bjorne Stroustrup inventor of C++:
“I like my code to be elegant and efficient. The logic should be straightforward to make it hard to hide for bugs, 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.”
There are couple of basic, well known rules, we should keep in mind, when we are writing code:
- During every day programming we spend a lot of time on reading (debugging ) code, so we need to always take care of writing good code, which will be easy and nice to read for someone else and also for us, we need to keep in mind that we are like an authors and we have our readers J
- Our methods should be no longer than 100 lines of code (one screen)
- We should add good, meaningful names for each classes, variables, packages, methods… etc. “So take care with your names and change them when you find better ones.”
- When we encounter on big method, which doing a lot of different things we should split it on couple of smaller methods
- I really like Boy Scout rule: “Leave the campground cleaner than you found it” – it hard to find hours on cleaning code, sometimes clients don’t want to pay for such tasks, so follow this rule we should do code refactoring every time when we are working on current tasks. When you see that something is easy to refactor and it will take you 5 minutes just do this.
I want to also mention that strongly related with clean code subject, are five based object programming principles, called SOLID:
- Single Responsibility Principle: “A class should have only one reason to change”.
- Open Closed Principle: You should create classes which will be easy to extend their behavior without changing and modifying it each time when some new condition appeared. Make classes open for extending, closed for modifying.
- Liskov Substitution Principle: “Function that use pointers or references to base classes must be able to use objects of derived classes without knowing it”
- Interface Segregation Principle: Classes shouldn’t been force to use methods they are no used. Instead of this using such interface we should create new one, which will meet our needs.
- Dependency Inversion Principle: Classes should be dependent on abstraction no on concrete implementations. If you want to have property for storing list in some class declare it as List instead of LinkedList or ArrayList
These are couple of accurate statements, which I found in book and I want to share with you:
- “You will not make deadline by making a mess” – Robert C. Martin
- “Don’t comment bad code – rewrite it.” – Brian W. Kernigham, P. J. Plaugher
- “If a name requires a comment, then the name does not reveal its intent.” – Robert C. Martin
- “Passing a boolean into a function is a truly terrible practice. It immediately complicates the signature of the method, loudly proclaiming that this function does more than one thing. It does one thing if the flag is true and another if the flag is false!” – Robert C. Martin