Bug Proofing Visual Basic: A Guide to Error Handling and Prevention (Wiley Computer Publishing) [Paperback]

If you're an advanced VB programmer (already have made many mistakes and have taken up defensive programming), this book could be reduced to 1/3 the size... and it would still be a great book.

I'll use code from this book. I particularly liked the discussion on how you could set a form (object) to Nothing and later in your code you reference a public variable in that form (and unbeknownst to you it loads again). This keeps the form loaded when you think it's not. He shows coded examples of this sequence.

After reading this book, I'm going to get his other VB Graphics book. He's a very good author.

One thing I wished he had covered was Error handling when using Access database routines (non-databound). I like to use subroutines that update separate tables, and I like to use .BeginTrans, etc. with the .Update method for the opened database. This allows me to simply use SQL statements.

In this case, I was looking for example code, or recommended logic for using multiple subroutines. Although he didn't specifically provide this, he did provide alot of ideas on how to control the Error calling sequence using the .Raise method. Thanks to his book I understand this process better and hope to solve this problem directly.

For the beginning programmer this is an excellent book for establishing your programming standards. You will make a great step forward in programming... although you may only understand 80 % of this book.

This should be in every VB programmers bookshelf.

John D.

The author discusses a logical convention of how programmers may write their code so that it will be readable and understandable by the next programmer who may not be as knowledgeable. By using properly descriptive variables, clear comments, straight-forward code styles, and no corner cutting, an application can be debugged easily by another programmer long after the first programmer has left the company. This would be good for department managers in establishing project standards for multiple programmers.

Furthermore, logical methods are explained for capturing bugs that can be kept in or deleted from the compiled code without having to manually delete code lines before a compile. Rod Stephens's techniques have prevented me from making mistakes that it would take a professional programmer years to learn.

Finally, his website shows all of the errors in his book (very few) and provides downloads of all of the code including improvements in the end-of-chapter questions.

Avoiding bugs, it seems, has much to do with following good programming practices and perhaps that should have been the book's title. Much wasted time is spent on telling us how to indent lines of code, how to line up our comments, and admonitions to fix our own bugs and to be alert when you test.

There was 20 pages of good stuff and the rest was fluff. It was as if Rod Stephens needed to put out a book fast and just shotgunned his many years of programming experience at us, hoping something would stick and save us from having too many bugs.

I realize I now own 4 of his books, but none are even in my top 10 Visual Basic books. If I could have read the book first and then paid for it, I would have paid 5 bucks.