Book Report: Java by Comparison

Welcome to my first book report since my high school days. I’ve chosen to write about the book Java by Comparison primarily because it’s the book I wish that I wrote. There are plenty of excellent books on specific frameworks and libraries, but this book doesn’t concern itself with this. Instead, this book with its multiple topics and 70 examples presents the best general approach to coding in any situation. As an instructor in computer programming, I consider how you code is as important as what you code and this book may be the finest example of instruction in how to code.

The book is presented in nine chapters or comparisons, each of which examines one aspect of the programming process. The first comparisons, entitled Start Cleaning Up, is where I found some of what I refer to as best practices when coding. In the introduction to this chapter the authors wrote:

Writing code that’s easy for humans to read and understand is much harder than writing code that compiles.

This is a sentiment I agree with. Submissions from my students that compile and execute are not a guarantee of a good grade. My students will be graduating and joining teams where code will be shared. My favourite section of this first set of comparisons is Ensure Code Symmetry. This is something I see in my students work where multi line switches or if/else statements deal with conditions that are unrelated to each other.

The second set of comparisons is entitled Level Up Your Code Style. One of my favourite topics here is Favor Java API Over DIY.  Sometimes I feel that programmers, by this I usually mean my students, do not spend enough time reviewing the APIs that Java offers. The result is reinventing the wheel. I tell my students that the APIs were written by programmers far more intelligent than myself and them. I even learned a new API in the Collections library called ‘frequency’ in this chapter.

Use Comments Wisely is the third set of comparisons and possibly my favourite. Its is not enough to have comments but rather to have meaningful comments. In the introduction to these comparisons they write about documentation for a smart TV device:

In the section titled “The Record Button,” all it says is, “Starts the recording.” Anyone could figure that much out just by looking at the red Record button! And what happens if you hit the Power button during recording? It doesn’t say.

They then go on to explain the best practices for comments. I especially like the advice to include examples of usage in the comments.

The fourth set of comparisons, Name Things Right, addresses one of my pet peeves, how identifiers are named. I frequently find myself assisting my students in debugging their code. I’ll see an identifier in their code and ask what this class does. The answer is often that its not a class but an instance of a local variable. The same happens when class names begin with a lower-case character.

The fifth set of comparisons is called Prepare for Things Going Wrong. In the section Expose Cause in Variable it is proposed that custom exceptions can best be used to describe errors specific to the code you have written. Rather than try and pick a Java exception class closest to the problem, you should be creating custom classes that can provide the very specific information a programmer may need to understand what has gone wrong.

The sixth set of comparisons, Assert Things Going Right, discusses the best practices for unit testing. It starts with the excellent advice in the section Structure Tests Into Given-When-Then. This will become part of my lectures on unit testing. There is one recommendation where I disagree with the advice to avoid @Before/@BeforeEach. The authors write that explicitly calling an initializing method is cleaner than using the implicit @Before method. On this point we will agree to disagree.

Design Your Objects is the seventh set of comparisons. Here is an excellent discussion called Avoid Returning Null that demonstrates how using instantiated but empty objects are a better return value for indicating a problem rather than just returning null. As Java evolves through its six-month release cycle, I expect two Java constructs to disappear. These are ‘new’ and ‘null’. Until then this set of comparisons is full of excellent advice.

The eighth set of comparisons, Let Your Data Flow, looks at functional notation. While some programmers think of the functional approach as an alternative to object-oriented programmers, the authors point out that the functional style is best used to enhance OOP. Here I see something I tell my students, use a stream rather than a loop when every element must be visited. It is counter intuitive for some new programmers because so much time is spent explaining loops in their courses. I have even suggested to my students that the ‘for each’ syntax should rarely, if ever, be used. Use a stream instead.

The last set of comparisons, Prepare for the Real World, addresses important issues as a project nears or goes into production. There are fewer code examples here. One topic that I am fond of is called Favor Logging Over Console Output. At my school I teach in the final year where students work on a single project for the entire semester. They arrive ready to use System.out.println whenever they want to investigate a specific method. They are shocked to learn that after I present the topic of logging they are now forbidden to ever use console output again. I threaten to come to their workplace and admonish them if I ever hear they used console output for debugging.

One of the many features of this book that makes it a must read and companion for every programmer is the code examples that illustrate each of the book’s concepts and advice. The book shows the before and after for each topic. Examining these practical examples while reading the book significantly enhances the written text. Taken together, the written text and the code examples, makes this book a must read.

I bought this book as an eBook for retail. It was one of my best investments as both a programmer and an instructor. I plan to make it a required text starting in Fall 2019. Let me end with some lines from the last chapter that describe what the authors expect from you after reading the book.

Now, you’re able to

• Spot problematic Java code quickly and know how to improve it.
• Recognize common types of bugs and know how to avoid them.
• Explain why one code is clean and another isn’t.

Ken Fogel, Java Champion, Montreal, Quebec, Canada, 2019-02-13