I got Java By Comparison from Amazon a while ago. I wasn't impressed with what my initial page flipping showed me.
I skimmed it and largely evaluated based on name and example code. Feel free to ignore my review based on the fact I skimmed.
Any Code Crafter book has to have two things for me to consider it worth purchasing AS a code crafter book.
No Getters.
This advocates doing getters, No.
"In object-oriented programming languages, you usually try to avoid direct access to the fields of a class from the outside".
I can't recommend the book from this line alone. This compromises the whole premise of object oriented programming.
This is the mindset that allows getters and setters to be OOP; "It's not direct access, so it's ok". No. It's a massive violation of encapsulation and you can't write object oriented code if you have getters.
No Nulls
I think any programming guide that recommends on how to deal with nulls other than, "Don't allow them into your code" is doing our industry a massive disservice. If there's recommendations as such, I can't recommend it as a book to improve yourself towards becoming a crafter.
Knowing how to handle nulls in legacy code - excellent; good to know. I look for heavy emphasis on keeping nulls out.
This book doesn't have no getters and it's take on no-nulls is as weak as Uncle Bob's in Clean Code. As such, I can't recommend it as a book to become a software crafter.
It has things to do that make your code better - and so other developers don't hate you... Might be worth it for those aspects. Though the summary suggests another book.
4 Line Summary
My summary of the book is 4 lines.
- Code Works
- Conveys Intent
- ...
- Fewest Elements
Guess I can do it in three lines. I didnt see anything in here around "No Duplication".
Everything the book presents are all excellent things to do to not write pure crap code. They're not going to make you be a crafter. I spent 15 years writing code according to these types of rules - and my code still sucked. I wasn't a crafter, not by any stretch. There's two primary reasons - I had getters/setters and let nulls in.
Reject these two; and so many recognized good practices become easy to implement. They almost fall into the code. What makes great code comes from these.
There are a few other notes I made where I disagree that don't fall into the buckets above or I want to call out.
No Switch or else
Java, as this book is about, is an object oriented language. The use of switch is detrimental to object oriented programming.
This particular point (no fallthrough) also hits the first rule of simple design - Does the code work. If it falls through unexpectedly, the code doesn't work and isn't appropriately tested.
if-else if-else chains are just switches in disguise (or the otherway around since switches tend to be more limited). These force procedural code. We're in an object oriented langauge; make it object oriented, not procedural.
Format concerns
Using line spaces as logical separators means your method is doing more than one logical things. The correct advice is not to "group with new lines" but to "extract into multiple methods".
Type knowledge
Don't require casting in your code. That's bad code. An if to avoid a null pointer exception is bad code. Stop it. Suggesting to do type checking is suggesting to write bad code.
Comments...
12% of the book is dedicated to comments. There's some points about how to use braces. It's dependent. The procedural code style promoted in this book; Braces are hella important because methods are doing way too much. That's the smell, not "do you have braces"
The book is recommending commenting for "Documenting Implementation Details". ... No. Just... No. If there's a implementation detail that's critical to knowing how to use it - Use the second rule; Convey Intent. Name things appropriately. Use appropriate collaborators. Instead of a comemnting the code of a collection to say it needs to be sorted, have a "SortedList" class. BAM! No comment needed. The class does what it says it does!
If you need to write a paragraph explaining your regex... Maybe regex isn't the solution? If you have tests, show all these things in the tests. That's where behavior should be documented. Not some comment that probably won't be updated when the regex changes.
Summary
If you need to advice on how to write better java code (Not OOP, just java) I'd pick up The Elements of Java which isn't about being a crafter (nor is this book, IMO). It's to make others hate you less when they look at your code.
Also Effective Java which has better OOP elements to it, but still bits I'll say a shouldn't be in OO code.
This book, IMO, misrepresents what it can help you do. You won't be a crafter from applying just these practices; you have a lot futher to go. It will help other engineers hate your code less though.