As a software developer you are facing many different tasks you have to deal with. Requirements have to be gathered, architectures created, algorithms selected or designed, tests specified, changes considered and finally (and not to an insignificant part) code created and modified.
Like in the other areas of software development, one question arises also in the latter case: How does professional, ”good“ code look like? How should code be written to create a working, powerful and maintainable system?
A simple answer: clean.
And how exactly ”clean code“ should look like and how you write it is explained in a simple and pratical manner by Robert C. Martin in his book ”Clean Code: A Handbook of Agile Software Craftmansip“. The book is part of the Robert C. Marting Series, which also contains several other interesting books about agile software development. Martin is the founder of Object Mentor, Inc. and is one of those people which are just part of the community of professional software developers.
The book caught my attention about one year ago and I just read it the second time from cover to cover. Admittedly, this is no special achievement, if you consider that this book only has 411 pages (including the appendices, which contain long listings of code; without those it has 315 pages) and is very well written. Anyway, it is absolutely worth reading multiple times, because on the one hand it contains a wealth of information and on the other hand you can constantly question and improve your own coding style. And this is what Martin eventually wants: better programmers and thus better code.
Right at the beginning of the book, Martin removes one doubt: Is ”good“ code important, anyway? According to him, and I totally share his opinion, this question can only be answered with ”Yes, of course!“ Even though the importance of hand-written code is constantly questioned because of the continually improved methods for code generation, the exact and executable specification of a software system will eventually have to be something, that can only be called ”code“. The idea, that someday it will be possible to more or less vaguely describe something to a computer, which will then make a perfect, executable application out of it, will always be an illusion. And thus, the job of a programmer and the importance of good code will continue to be an important part of software development.
The book is divided into three parts. The first chapters introduce, with many code examples, the basic principles of good code. The middle part gives three case studies, which illustrate the methods of developing good code. Finally, all the principles and patterns of good code are summarized into so-called ”smells“, which can be used to name problems in bad code (the idea of ”code smells“ was originally introduced by Martin Fowler in his book ”Refactoring“).
Most of the principles and ”rules“ are actually quite obvious, but it’s still worthwhile to explicitly have a focus on them. As simple as well-known rules like ”Use descriptive names“ may sound, as important it is to go into the details and think about what actually makes a name descriptive in the first place. While reading the book, it is quite amazing how often you have to think ”well, that’s obvious!“, only to admit shortly after that you are actually not always sticking to the rules yourself. Only very few principles are less obvious and also a matter of taste or style sometimes, but this is mentioned right at the beginning of the book. While, for example, most of what is said about comments is right (especially that they do not replace good, self-explanatory code), you might indeed have a different opinion on the deprecation of HTML formatting in Javadoc for example.
But the sometimes very specific ”rules“ (like in the example about comments) should not mislead you: as a whole, the book tries to convey more general principles and concepts instead of a specific programming style. Martin speaks of a ”code sense“, a kind of a sixth sense for good code, you should develop over time. Because this already is a difficult task to undertake in a book, he concretely uses his own programming style as a standard, which is consistently used throughout. It is eventually left to the reader how much of the programming style he or she adopts directly and how much is adapted to his or her own style.
Anyway, the chapters which describe the ideal target state of the individual parts of a program, like variables, functions or classes, are only the basis for the rest of the book. Because the ”trick“ to write good code is not to write it right from the start. According to Martin this isn’t even possible at all, instead, programming is more like writing prose: you start with writing a rough draft, which already contains everything, but doesn’t read well yet. Then you start to iteratively bring the text into its final, readable shape. Transferred to programming this means: First it has to work, then you make it nice. The important thing here is not to skip the second part and say ”at least it works and there is currently no time!“. Statements like this are short-sighted and usually lead to a steadily slower development process over time in the first place, just because modifying and maintaining the old, ”bad“ code is more complex and more tedious.
How this approach works in practice is impressively demonstrated by Martin in three case studies. He shows step by step and with reference to the different principles how clean code evolves from working, but bad code. In doing so, it also gets clear how the subject of the book is connected to other books about agile methods: the basic requirements for this transformation are for one thing automated (unit) tests and for another thing the methods of refactoring. And even though this book gives a short introduction to both (especially unit tests/test driven development) it is worth it not to stop here and continue with the respective standard works ”Test Driven Development“ by Kent Beck (http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530) and ”Refactoring“ by Martin Fowler et al. (even if you already read them).
In the last chapter Martin summarizes the presented principles of good code into patterns of the Fowlerian ”code smells“ and thus gives the means to use the book as a reference. This can also be useful for communicating with other developers, because you can now easily justify changes or point out deficits in commit messages or bug trackers by using abbreviations like G5 (”Duplication“) or N1 (”Use Descriptive Names“).
In summary, I can absolutely recommend the book to everyone who perceives him- or herself as a professional programmer. Though, code is not everything when doing software development, but a professional approach is simply necessary here too.
The next article will contain some comments about some ”smells“ of which I think that they aren’t that well justified in the book.
This entry was posted on September 19th, 2010 at 9:33 PM. It is filed under General, Programming and is tagged with agile methods, book, code, software development. You can follow any responses to this entry through the RSS feed. You can leave a response, or trackback from your own site.
