Author: Dr. Simon Harrer, Dr. Jörg Lenhard and Linus Dietz
Publisher: Pragmatic Bookshelf
Pages: 208
ISBN: 978-1680502879
Print: 1680502875
Kindle: B07CLFTVZS
Audience: Java programmers at just the right level
Rating: 4
Reviewer: Alex Armstrong

Learn Java by comparing the good against the bad - sounds like a good idea!

This book is based on a simple principle - that you can really only learn what is good by comparing the good with the bad. What happens is that a, usually small, chunk of Java code is presented and discussed and along the way its problems are pointed out. Then an improved version is presented and explained. With this approach you really can't help but see that the better way really is the better way.

However, there are a few smallish problems with this book. The first is that its title "Java by Comparison: Become a Java Craftsman in 70 Examples" implies that you can learn Java this way - you can't. You have to be reasonably good at the language to understand the comparisons. If you are too good then you will simply regard the advice as being obvious. For a good Java programmer this book is, at best, an exercise in making what you know intuitively explicit.

For example, Chapter 1, entitled "Cleaning Up", is about some very basic best practices. For example, don't compare functions that return a Boolean to true or false. That is, don't write:

if(myFunction()==true)


write:

if(myFunction())


This is blindingly obvious, but who knows there might be a reason for wanting to make clear that the function does return a Boolean and what about

if(myFunction()==false)


compared to

if(!myFunction())


Ah, but the next comparision shows that you can always get rid of a negation by swapping the if and else parts of the statement. This is true enough, but sometimes you want the most likely occurence to be the if part and the rare exception to be the else part. Yes, these are all refinements but not all refinements make code more understandable in all situations. At least they are making you think about code

The book continues on in this fashion and most of the time the comparisons are at a level that should make you say "of course". Chapter 2 is about coding style and contain lots of well known best practices such as replace "magic" numbers by named constants. There are also some more modern idioms such as favour for each over iteration with an index - unless of course you need the index.

Chapter 3 is on the most controversial aspect of programming ever - comments! Yes, we all know that writing "add A to B" above A+B is a useless comment, but how do you write good comments. This chapter might make you think a bit harder about the problem but it is still a tough problem. This general idea carries on in Chapter 4 where the subject is how to name variables - just as tough as comments. In fact a good naming can make a comment unnecessary. The problem here is that the whole thing is wrapped up more into a single aspect of how to make code more understandable to programmers who didn't write it.

This sort of ends what you might call the "classical" section of the book. You will find all of this advice about Java scattered about in other books and articles and on other languages.

Chapter 5 deals with a slightly more recent topic - how to write and handle exceptions. For my money throwing exceptions is easy, catching them is easy, making sure that the program continues without crashing is more difficult. Chapter 6 is about the even more modern, relatively speaking, topic of unit testing. Chapter 7 is about object oriented design but as it tackles only the fairly straightforward topics there is no danger of firing a controversy. This is not deep object oriented design more a collection of easy to understand pointers on how to go about it. Chapter 8 does a similar thing for functional programming - but as Java isn't a functional language this is less successful. It is basically about using a fluent calling style and how not to make a mess of it. This is not real functional programming as, say, a Haskell programmer would think about it and this is a good thing.

The final chapter is a collection of advice on how to deal with software in the real world. It covers topics such as continuous integration, use a logging system and build system and so on.

Conclusion

This is a fun book to read if you have the right level of Java - not too beginner and not too expert.  In most cases, if you are a reasonable Java programmer, you will think or even say out loud, "yes of course". I'd recommend that you take a slightly more critical angle because not all of the advice given is good in all situations. It all depends what you are trying to do and the code that surrounds the tiny snippets that you are presented with. You will be a much better programmer if you question all the glib advice that you are given even if it is backed up with fairly convincing examples as in this case.

Recommended, but only if you are at the right level of Java expertise or you like saying "that's obvious" quite a lot of the time.  

To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.