Full disclaimer up front: I received a free copy of the book from one of the authors in exchange for this review.
This book is an interesting take on Clean Code or software craftsmanship. It’s well written and full of useful content, but it’s not for everyone. Keep reading to find out if the book might be a good fit for you.
You can find more information about the book on its dedicated webpage java.by-comparison.com.
The authors came from a university background, where they wanted to teach students how to write better code. After explaining the same concepts over and over, they collected it all in the form of this book to refer others to. This approach actually shows itself surprisingly well when you read the book as an advanced developer.
The book follows a pretty strict format (except for the final chapter), in that it provides piecemeal little nuggets on each pair of pages. On the left page you get an example of bad code and on the right page an updated version that improves upon it based on one particular idea. The explaining texts help the reader to understand why a certain code is considered bad or good.
The individual concepts are loosely coupled into thematic groups so that you always get a bunch around a similar topic (f.ex. testing or functional programming style). It feels a bit strange that the number of concepts is 70. That gave me the impression that it’s not the real number but chosen for cosmetic reasons – meaning that either some principles were left out or some trivialities were added to reach that “nice” number. Then again, any number would have been like a “magic number”, so maybe it would have been best to not use any number at all.
The concepts in themselves are nothing new or out of the ordinary. They are all about proven best practices and I rarely found myself in disagreement and if I did it was more about some finer point in the explanations than the principles themselves.
In this respect, the book compares to Robert Martin’s Clean Code book, which also provides a large number of principles to be applied to your code base. Since both are really good books, which one should you read if you had to choose? They both have their pros and cons of course. If you pick up the original Clean Code book, you’ll get Java examples as well, but the discussion of the principles is far more thorough as it is not limited by the two-pages format. The principles themselves are of a higher level such that they apply to pretty much any modern OO language, whereas in “Java by comparison” a lot of the principles directly address specific Java problems, solutions or APIs. In terms of readability or understandability though, the book reviewed here surpasses Robert Martin’s book significantly. The authors spent their fair share of time explaining these topics to probably hordes of students and as a result, their explanations are short, to the point and easy to follow. What they lack in depth they certainly make up for in clarity.
Usually this is really easy for me to address, but not in this case. The authors themselves propose that you solve the infamous fizz-buzz problem in order to find out whether the book is for you. If you can’t do it, the book’s probably too advanced for you. If you can do it in your sleep, you’re not the target audience either. If it takes you a little bit and requires some concentration, then they claim the book is for you.
Now would I recommend the book to beginning professional programmers, i.e. people freshly graduated and within the first year or two of an actual paid position where they do development? It depends. For my co-workers I would not. I believe that the value of having a mentor showing you the ropes of our business far succeeds the book’s impact. For someone who is not fortunate enough though to have the luxury of a senior developer supporting them, the book is better than a lot of other options.
Never mind the authors’ point of view, I’d actually say here that the target audience specifically are senior developers. You will probably not learn anything at all from the book, but it seems to be a really good companion when mentoring others. The authors explained this use-case as well: similarly, to teaching student after student about a topic, you can simply refer your mentee to a certain chapter and save yourself a lot of explaining. You should still do a lot of explaining afterwards, but at that time you can focus on some finer points or the applicability of the principle to some situation at hand.
From my experience, knowing certain principles of good code is really just the half of it. The book itself can’t get you to the intermediate level, and lots of practice without feedback from an experienced developer is just an excruciatingly painful and slow experience. But once you are in the situation of being able to get solid feedback, the value of the book diminishes significantly.
As mentioned above, the book has a solid didactic grounding. It is easy to follow along for each principle and you can digest it at any pace you want to. The book is well-written – for once the editors did a good job there. I’m disappointed as I’m writing this, but given the books published throughout the past years, I feel it is worth mentioning that there are still writers out there who struggle so that their readers can enjoy good sentences, instead of having their readers struggle to extract meaning from their gibberish.
A small aside: The subtitle of the book refers to the term “craftsman”. As of recently, this term has fallen into disgrace for the seemingly obvious reason that it specifically addresses the masculine gender only. As a man I feel properly included in this term, but can fully recognize the inclusion problem it causes. As far as I can tell, the discussion on what “software craftsmanship” should be called to be more inclusive is still ongoing. Fortunately, the authors didn’t really pay much respect to their subtitle and in contrast to books from certain other famous authors, this sort of bias is not pervasive throughout its content. I probably wouldn’t have noticed anything if not for the recent discussions that made me aware of this clumsy term.
Ultimately, Java by comparison is a really good book, albeit for a rather small target audience. The harsh focus on the Java language may make it appear more prominently in that community, but I’m afraid the book loses out on a lot of value. Even on the JVM readers may want to discuss these principles in the context of Kotlin, Scala, Clojure or any of the other fine languages.
Finally, the format of the book is perfectly suited for a web-based reference of these principles. Tools like FindBugs already include explanations for their analysis results and code samples of how not to and how to write code properly. The book just increases the depth on these explanations and it would be amazing to see that integrated with the tooling for everyone to use. I have already seen these tools become mentors for junior developers. The tool’s not a person, so it is easy to deal with – no need to have some person tell you that your code may be suboptimal. I would love to see a website that compiled the principles from the book and others across all programming languages, so that developers and tools could have a resource that could bring our entire profession to a new level of professionalism whilst even making it more inclusive by opening up this body of experience to everyone. Until that time, the book is a decent alternative – at least for Java developers.