As code reviews have become the norm in programming, rather than a practice found only in vanguard development organizations, it has become apparent that the industry lacks a way to name and refer to corrections for poorly written code. In this sense, code reviews have needed the kind of terminological advance provided by Martin Fowler’s book, Refactoring, which gave names to different ways to remediate code (extract class, pull up method, and so forth).
Java by Comparison aims to fill that gap by specifying the cures to 70 common Java programming infelicities. Each less-than-desirable coding choice is explained across its own two-page spread in clear, concise language that any beginning or intermediate developer will find approachable and instructive.
The explanations start with an example of the poor practice and then spend much of the rest of the time articulating why the practice can lead to undesirable results. And then, as you’d expect, the authors show how to correctly write the code. For this reason, the book is invaluable in code reviews for pointing out to programmers who don’t understand why a particular piece of their code, which works and passes all tests, needs to be rewritten. Instead of spending time explaining the point, reviewers can simply point programmers to the appropriate entries in this book.
Some of the explanations are of well-trod advice, such as “avoid returning nulls” and “use Java naming conventions.” Some move up the complexity spectrum, such as “parametrize [sic] your tests” and “favor method references over lambdas.” There are a handful of even more-advanced recommendations, such as “use collect for terminating complex streams.” And the authors have included a small set of process-oriented recommendations, such as suggestions to use static analysis, continuous integration, and so forth, which don’t really fit here and probably would have been better replaced with other code-level recommendations.
Books like this one are excellent for their intended readers: beginners and intermediate developers. In fact, beginners should read the book cover to cover to understand all the conventions they need to bear in mind, whereas intermediates can use the book more as a reference volume. For these roles, I can highly recommend this slim volume, despite occasional faulty English. (For example, parentheses occasionally are referred to as brackets.)
However, I strongly suggest getting the electronic version. The hard-copy version (which is my normal preference for reference works) is unusable because the publisher printed the code in gray on a gray background, making it illegible in all but the brightest light.