“Clean Code”, by Robert C. Martin and guest contributors, is frequently mentioned as one of the top books that software developers should read. I had been wanting to read the book for years, but I knew that it would require a big time commitment. Since I had a goal of reading one tech book a month this year, I decided it was time to take the plunge and finally read it!
I was fairly certain that I would learn a lot about good coding practices, and I definitely did. But what really fascinated me was the emphasis on testing! The author states that it’s not possible to refactor code well unless you have good tests in place. He sites this example from when he was coaching a team who decided that their test code didn’t need to be maintained to the same standards of the production code:
“From release to release the cost of maintaining my team’s test suite rose. Eventually it became the single biggest complaint among the developers. When managers asked why their estimates were getting so large, the developers blamed the tests. In the end, they were forced to discard the test suite entirely. But without a test suite they lost the ability to make sure that changes to their code base worked as expected. Without a test suite they could not ensure that changes to one part of their system did not break other parts of their system. So their defect rate began to rise. As the number of unintended defects arose, they started to fear making changes…Their production code began to rot.”
As someone who is passionate about software quality, I knew that automated tests were crucial. But I didn’t realize just how crucial they were for simply keeping production code clean and updated!
In one of the main sections of the book, the author gives an example of completely refactoring a parsing tool that he had created. One step at a time, he pulls out arguments from functions and puts them in new functions, creates interfaces to reduce code repetition, and so on. The reason he is able to make all these changes to clean up his code is that he has tests in place! He begins his refactoring by making sure that all the tests pass. Then he makes one change at a time, running the tests after each change. As long as the tests continue to pass, he knows he’s not breaking anything.
Software testers might be reading this review and saying to themselves, “This is great! I’ll tell all my developers to read this book.” While that is a great idea, software testers need to read the book too. Because now that we know that the quality of test code is just as important as the quality of production code, we need to write really clean code as well!
Some of the important clean coding principles outlined in this book are:
• the name of a variable, function, or class should tell you why it exists, what it does, and how it is used
• functions should do only one thing, and they should do it well
• functions should either do something or answer something, but not both
• functions should be read from the top down: if function A calls function B, function B should be listed below function A
• strive to use as few arguments in a function as possible; two should be the maximum
• avoid writing comments as much as possible; the code itself should clearly state what it does through good naming
• standardize on common spacing practices, so everyone’s code looks the same; this will make it easier to read
• don’t leave commented-out lines in the code; either delete them or fix them. The longer they are there, the more others will be afraid to touch them for fear of breaking something, and they will clutter up the code
I learned all this and so much more in “Clean Code”. I recommend that everyone who writes any type of code, production or test, take the time to read this book and put its recommendations into practice.