Most Helpful Customer Reviews
12 of 13 people found the following review helpful:
5.0 out of 5 stars
This book is money for IT professionals, September 14, 2000
By A Customer
This review is from: Debugging Java: Troubleshooting for Programmers (Paperback)
This book is money. The ideas and concepts in this book will probably recoup the book's cost many times over every month you remain in the industry. It is hard to discuss technical matters in a clear manner. Will Mitchell does so with warmth, wit and humor. No mean feat in a technical book. This guy actually tries to explain his ideas, not impress us with his intellect. Probably 60% of this book will be useful long after Java is an old dusty language that people used to use. I think that just about everyone in data processing would benefit from this book whether they use Java or not. I have been programming for over twenty years and I wish I could have read this book in the beginning. I have learned most of these principles and ideas the hard way. The rest not at all until now.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
7 of 7 people found the following review helpful:
1.0 out of 5 stars
Only old-timers and newbies will like this book, January 9, 2002
This review is from: Debugging Java: Troubleshooting for Programmers (Paperback)
First let me say I liked the writing style and it was enjoyable to read. I was able to finish the book cover to cover in 3 days of casual reading. I did get something useful out of the book. He talked about right-brain versus left-brain activity which I found interesting and helpful for my job. I've made the mistake of reading Extreme programming and Refactoring BEFORE reading this book. So for example in this book the author spends great detail on how to count in a large switch case statement how many case: elements you should have and how to quickly check it. If you've read Refactoring by Fowler you would instantly hear alarms in your head telling you your NOT using OO corectly and that this bad code should be refactored. If you want a good OO/Design Patterns book I would recomend Cooper's book. You better understand Design Patterns if your going to code in Java or you will have a tough time when it comes to I/O and Swing classes. Two finally points to make on the downside of this book.
1. The author mentions 'goto' and does not correctly tell the history of why the word is reserved. James Gosling at OPSLA on year informed the audience that a technical writer was documenting 'goto' and wanted him to explain it. When James did a grep against the code base he saw it used 10 times of which only 3 where valid in his opinion. James then decided it was easier to remove it than it was to have it documented. James felt that continue and break statements handled all cases that goto were being used in the system. 2. The exception model in C++ is just plain broken and the author does not do a good job of explaining what Java did to fix this problem. In a very large C++ system any 3rd party library could throw an exception that is un-advertised. Exceptions in C++ are checked at runtime. The Java compiler checks exceptions at compile time. In java you could never add a 3rd party jar file and have an exception thrown that is not advertised in the interface of the class or method. Java is an OO language and to debug in Java you better know OO and you better understand threads and java.object or your going to have a long night. The author should have started here and delved deaper instead of wasting paper on MS Word and Word macros for coding. Ah...
Before I forget. If you read the book PLEASE don't use /** QQQ*/
as a tag in your code. If you've got JBuilder use /** todo */ or something non-cryptic to document coding in progress comments.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
6 of 6 people found the following review helpful:
2.0 out of 5 stars
Is He Serious?, November 5, 2001
This review is from: Debugging Java: Troubleshooting for Programmers (Paperback)
A while back I picked up 'Debugging VB' and didn't think much of it. At first I thought 'Debugging Java' was better, but the author completely blew his credibility on three counts: 1. Not only does he recommend using MS Word as a Java IDE, he goes to some length to provide macros and so on to show how to achieve context-sensitive highlighting and so on. In fact, at the back of the book, several pages are devoted to this very thing. 2. At one point he writes with pride about how he whipped up a 'report generator' in Basic that cranked out 25 copies of boilerplate COBOL. Precisely the kind of code that Java's inheritance and object composition paradigms are intended to avoid. Some people never learn! 3. In a similar vein, he also takes about a faux Javadoc he developed that cranked out 1" of documentation in half a day. This fellow seems to prefer quantity over quality. On the plus side, this book had a better-than-average discussion of the various IDE's (other than Word!), and is worth a quick peruse to see what they all look like, if you haven't already.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
|
