Clean Code – A Handbook of Agile Software Craftsmanship (free ebook download)8 min read
Even bad code can function. But if
What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.
Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
Readers will come away from this book understanding
- How to tell the difference between good and bad code
- How to write good code and how to transform bad code into good code
- How to create good names, good functions, good objects, and good classes
- How to format code for maximum readability
- How to implement complete error handling without obscuring code logic
- How to unit test and practice test-driven development
This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
Robert Martin on Functions
To summarize, here are Martin’s basic premise on how to name functions: Functions should be small, use meaningful names, and have no more than 2 parameters. Martin’s decree on functions falls in line with his view of comments. He feels comments should almost be non-existent and the function names should describe themselves. Comments should only be used to describe intent or to clarify when clarification is needed.
Robert Martin on Classes
Martin most harps upon the fact that the classes should be small and must follow the Single Responsibility Principle (SRP), described in his first book. The Single Responsibility Principle states that a class should have only one reason to change. Martin equates “one reason to change” with “one responsibility”. To illustrate his point, Martin shows a class that inherits from a GUI component and also tracks version information. This class has two reasons to change. The version info can change, regardless if the GUI has changed or not. He also goes on to mention that SRP is one of the principles that is most abused by mediocre coders. If you are a seasoned developer, you may have come across a class that has too many unrelated things. What’s nice about the book is it describes why you need to follow this principle and how you can take existing code and make it follow this principle by refactoring.
Martin gives good examples of what a poor class or function looks like and how to refactor and rename variables to make the code more readable and more maintainable.
Test Driven Development
Martin, as are other agile proponents, are heavily into Test Driven Development (or TDD). Martin describes the three laws of TDD basically saying you need to write a unit tests in tandem with the production code. I think the laws can be improved by stating more specifically as to what exactly you are testing. Martin says the tests in TDD are testing production code, but what does that mean? Does it mean he is writing unit tests against a function? A class? A use case? I think the three laws need to be a little clearer.
In my experience, unit tests are centered around a test instance of a class. Unit tests are written around different functions inside the class and test different constraints of the function or the results of the function. So perhaps this is what Martin is getting at with the three laws.
Also tests can either test the state of the object or it can test the ability to interact as expected with mock objects. Martin doesn’t really talk about these different models.
Martin, however, does stress the importance of TDD, and gives examples through JUnit of how to write good unit tests against your code.
Dependency Injection
Martin describes the importance of dependency injection and using an IoC Container (Inversion of control container). An IoC container allows you to utilize a framework, such as Spring (Unity in the .NET world), to hook up the dependencies of your objects upon construction. He tells how IoC moves the responsibility of constructing objects away from the objects themselves, therefore adhering well to SRP. The nice thing about frameworks like Spring is you can describe all your dependencies in an XML file and easily manipulate the type of construction and dependencies of construction of different classes. Inside this file you can also swap in and out different concrete types. This is a powerful feature, because inside your code, you may just be passing in an interface into a constructor, but the IoC container describes which of the concrete classes is in the underlying object. An example of the power of dependency injection is say you wanted to provide data to a particular class through a data provider. You could create a constructor in your class that took an interface for all data providers. You could then, for example, change to a different data provider in your IoC container. The code for the classes receiving the data provider in their constructor (as an interface), would not have to change as long as the data provider you swapped out had the same interface.
General Coding
Martin does have a great section called Smells and Heuristics describing bad code to look for (although I found it ironic that he named one of the sections of the book General after describing in his book that it was bad to give meaningless names to classes, and here he is giving a pretty meaningless name to a section of his book). In any case, the code smells, as they are called, are gems because we all have come across them, and many of have certainly coded them. Here are some of them you might recognize
1) Dead Code – Advice: Remove it (use version control to track it)
2) Output Arguments – Advice: Put them in the class fields
3) Flag (Boolean) Arguments – Breaks SRP, Advice split the function in two.
4) Functions should do one thing – Advice: Break them up so that each function does one thing
5) Avoid negative conditionals.
6) Don’t pass null
7) Choose names at the appropriate level of abstraction
8) Prefer polymorphism to if/else or switch case
9) Use constants instead of
10) Encapsulate conditionals
11) Local variables should be declared directly above statements about to use them
12) Use descriptive names (this statement is made throughout the book in about 10 different ways, but can’t be said enough. From
Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.
Conclusion
Robert Martin’s book Clean Code provides a great set of guidelines if you are a professional coder. If you already code within the boundaries of Martin’s suggestions, then you are already a great coder. If you find that you do not adhere to a lot of these principles, but you “see the light” from the suggestions in the book, then you have taken the first steps to becoming a great coder that other coders will gain a new respect for. But most importantly, if you follow the suggestions inside the book, your job will become easier because your code will be easier to maintain, will be less buggy, and become more readable. You’ll also be able to extend your code more easily, and even better, others will be able to build upon the strong structure you’ve provided.
