Why You MUST Read Clean Code
Why You MUST Read Clean Code
Join the DZone community and get the full member experience.Join For Free
Whatever new awaits you, begin it here. In an entirely reimagined Jira.
Clean Code: A Handbook of Agile Software Craftsmanship written by Robert C. Martin is one of the best books I have read in the past few years. This is the book for developers looking to produce better code. To be honest, any developer, software engineer, project manager, team lead or system analyst who develops an application or just reads code, should probably have a copy of this book on their bookshelf. Even though the examples in the book are written in Java, the book provides relevant information for developers using any language.
This book is divided into three parts each filled with code. Part 1 describes the principles, patterns, and practices of writing clean code. Part 2 has several case studies. Part 3 is just one chapter containing a list of heuristics and "smells" gathered while creating the case studies.
Lets see the top 5 reasons why you should buy and read this book.
1. If you consider test code as second-class citizen.
If your team feels that test code should not be maintained to the same standards of quality as production code than you should read this book. The author explains the three laws of TDD, how to keep your tests clean, and the five rules for writing clean tests called F.I.R.S.T. Let me just give you a sneak peek of the rules:
a. Fast Tests should be fast.
b. Independent Tests should not depend on each other.
c. Repeatable Tests should be repeatable in any environment.
d. Self-Validating The tests should have a boolean output. Either they pass or fail.
e. Timely The tests should be written in a timely fashion.
2. If you are using third party libraries.
Chapter 8: Boundaries discusses the best practices and techniques to keep the boundaries of our software clean. I admit, in all these years, I have written several lines of throwaway code to try these libraries. Once the code works, we add it directly in our production code. The author, however, shows us a completely different approach. The apache log4j package is used as an example in this chapter. To quote the author:
Instead of experimenting and trying out the new stuff in our production code, we could write some tests to explore our understanding of the third party code. Jim Newkirk calls such tests learning tests.
3. Throwing checked exceptions.
This is yet another topic that has been debated for quite a long time. If your code is throwing a lot of checked exceptions, you are returning a null in your catch block, and you have tons and tons of null checks everywhere in the code, then you should pay particular attention to Chapter 7: Error Handling. A few of the topics covered in this chapter with examples are:
a. Use Exceptions Rather Than Return Codes
b. Write Your Try-Catch-Finally Statement First
c. Use Unchecked Exceptions
d. Don't Return Null
e. Don't Pass Null
4. What's in a name?
Isn't our entire code base filled with names for our libraries, packages, classes, methods and variables. If you are naming your variables as i,j,k or methods are named like getList or getArrays than this book will help you write meaningful names. At this point I remember the following quote from the foreword written for this book by James O. Coplien
You should name a variable using the same care with which you name a first-born child.
The author uses excellent examples to show how to write code with meaningful names;
a. Use Intention-Revealing Names
b. Avoid disinformation
c. Use Pronounceable Names
d. Use Searchable Names and so on...
Not only does this book offer great advice, it also makes you laugh out loud(LOL). For example, while reading Chapter 2:Meaningful names, the author writes:
If you can't pronounce it, you can't discuss it without sounding like an idiot. "Well, over here on the bee cee arr three cee enn tee we have a pee ess zee kyew int, see?" This matters because programming is a social activity.
5. If your functions and classes are too long.
If you are doing too many things, have nested loops, and lots of indenting, go get this book. There are several chapters which show how to refine your code, reduce the number of lines within your function, and completely remove duplication. The author takes a few examples from the open source testing tool FitNesse, and uses FitNesse to refactor some of the long functions as he goes along.
If none of the above examples bother you because you are already writing clean code, than there are several more reasons to read this book. It wil help you with: Comments, Formatting, Objects and Data Structures, and many more.
What I learnt from this book:
1. To clearly identify between good and bad code.
2. How to refactor bad code to good code.
3. Giving good names to variables, methods, classes and so on...
4. Better understanding of error handling.
5. How to Unit test 3rd party libraries.
6. And finally, Cleanliness is next to godliness.
Enjoy. Share your thoughts if you have read this book.
Opinions expressed by DZone contributors are their own.