There is a lot of practical advice in this book. While it should be obvious that a developer needs to set up templates without hard-coding and make all procedures perform very specific duties, we find that this is not the case in code. The book has quite a few good pieces of advice around the basic nature of programming. I will disagree with the author, however, on some points. For example, you should certainly minimize fan out (calling many procedures) for all but control functions, fan-in (multiple procedures using the same procedure) is a sign of very specialized functions, which he advised only two pages earlier.

This book has a whole chapter on naming conventions, using Hungarian. While this is not a cardinal sin, it should be noted that Microsoft has deprecated Hungarian in .NET. The inclusion in the book (chapter 4) suggests that the author has simply updated some of his material from his VB 6 book.

The suggestions for enumerators, commenting, looping and code flow are fairly decent and may help your coding efforts. Mr. Foxall falls a bit short on exception handling taking the tried and true route (see Richter's book for a better methodology). One item of contention is the idea that you handle unexpected as well as anticipated exceptions. In general, handle what you can and catch what you wish to log. Let the rest get handled on the UI to ensure the user does not get an ugly exception message. Most books on the market advocate catching everything, and then rethrowing the same error; what a waste of CPU cycles. In VB 6, you had to handle every exception, and pass it up the stack if you caught anything. In VB.NET, exception handling gives you the ability to catch those exceptions that you can handle or log for debugging a live application. Using finally, especially with objects with a dispose method, is a much better option.

I would agree with the 1 star reviewer on the coverage of modules before objects. Modules are a sloppy method of programming in Visual Basic .NET. They are placed in for VB 6 developers that miss their .bas files. On the other hand, this is not enough reason to kill the chapter, as some of the other advice in the chapter (2) is very useful.

A 2.5 rating would be a bit better as there is some bad advice in this book, but I have to choose between 2 and 3 and would rather give the author the benefit of the doubt. I hope Mr. Foxall has a chance to make a second version of the book that moves completely into the .NET paradigm, as it would be much more useful to developers.