Review of Clean Code – Robert Martin
Author: Robert C. Martin (Uncle Bob)
Year: 2008
nº pages: 464
Estimated reading time = 65 days
Contenido
Review and summary of Clean Code
Clean Code has become a reference book for the programmers around the world. It explains some techniques and concepts that would allow us to improve our programming skills making our code more maintainable and scalable. Also it provides many examples on how to improve some code and pieces of code on how to transform it.
Robert C Martin has dedicated several decades to study the rules to create clean code, helping programming teams and managing big applications to be maintainable so his knowledge on the field is quite extensive and it is shown on this book.
The code examples are written in Java but they are simple and clear, so they can be followed by any programmer. Although it is recommended to make a slow and careful reading because the there are many details showed on each example, so grab a coffee and crush the book 😉
Key concepts to learn from Clean Code
In the next sections you can find the key lessons I found fundamentals from the book (sorry if I have missed some important ones, let me know at the comments box down there):
The usage of tests makes you develop faster
For the one not convinced yet that the best way to develop is using tests (and potentially TDD) here are some key concepts that will persuade you to use them:
- Having tests would help you to grant that the tested functionality works as expected. It may seems obvious but the code that you test, works as you tested, so you can grant that it works as it is tested (that is different as how product want it to work some times).
- Allow developers to change code that has tests raising errors when some functionality has been changed or de-gradated: once some code is having tests that check the functionality, any other developer can change the code and test if the new changes are braking some old code and introducing some bugs.
- On big systems, the only way to develop new features that potentially can brake old code is having a good battery tests that can raise errors when there is a braking change. So at the long run, having tests allow the teams to keep the same pace of development with the confident that there is no regressions introduced because of uncovered tests zones on the code.
As we can see, having tests help the teams to keep the same pace and on the long runs make that the projects can keep growing instead of investing every time more and more time manually testing that each new feature is not braking the old code.
The Boy-scout rule
The author introduces a rule that should be done: all the time that a developer analize and read code, it should leave the code better than he/she found it. Maybe modifying the name of a variable, refactoring some function or changing the names to make them more explicit. If we all do this rule we can understand better each other code and also have better code over the time each developer is checking the code.
Least surprise rule
If you wonder which change would be better to introduce while you are coding or refactoring code, choose the one that would make the less surprise to the users that will read the code.
Single responsibility principle (SRP)
Each function or portion of code should do one and only one thing. If all the code is build up following this rule, it would be quite easy to follow the logic, easy to test and highly module.
This particular principle is easy to spot on every code, if you find a function that if you read the name and check the code, you can see that you would need to add far more words to the name of the function you should split the function into other functions more descriptive that only do a single thing.
All the code should be at the same abstraction level
When writing code, usually we have different abstraction levels, for example if we are building cooking program, it should not mix functions like cook_the_pork with add_salt because they are in different levels of abstraction, and the same would happen with the code you write.
Here is an example of missing abstraction levels:
def print_options():
option = input('Select A o B')
if option.upper() == 'A':
print_a_colours()
elif option.upper() == 'B':
print_b_colours()In the example we can see that the functions input and print_a_colours are in different abstraction levels, input is a low level build-in while print_a_colours is a defined function.
A better implementation of the same logic that would help readability and logic integration is:
def print_options():
option_selected = get_option()
print_color_option(option_selected)
def get_option():
return input('Select A o B')
def print_color_option(option):
if option.upper() == 'A':
print_a_colours()
elif option.upper() == 'B':
print_b_colours()As we can see, now the function print_options has all the functions in the same abstraction levels, and the low level checks are into each function. The overall logic is the same but it is far clearer and more maintainable.
The deadlines are fixed but the amount of features to be included is variable
On the professional development of software we have some tasks to do, and some delivery times. Usually we estimate the time that each task would take us and we have hard delivery times.
So it is important that in order to meet the deliveries on time, we fill the time until the deadline with the features that can be fit and not with “all the possible tasks” based on the estimations of each task.
It is better to reach the deadline with less feature than don’t have anything to hand-in because there were too many half done tasks, while the deadlines are fixed, the amount of features to include on each deadline is variable.
About Robert C. Martin and Clean code book series
Known as well as Uncle Bob, he is a professional at software development. He started his career at 1970 and since 1990 he is working as international consultant for first class world companies.
He is the founder and president of Object Mentor Inc, company that offer consult services for development teams round the globe on different programming languages on fields like object oriented programming, design patterns, agile methodologies or extreme programming.
Robert C. Martin series books
This is the books series that Robert has written to improve our programming skills:
1 Response