I have used both the VB6 and VB.net versions in my classes. In fact I require this as a additional text for all my classes. I believe very strongly that Hungarian notation should be part of a program.

It sounds like these reviewers that don't like Hungarian notation program in a vacuum. It is alright if you program by yourself to through out notations but if you have ever been a code reviewer and had to try to figure out what datatype or control type was being used, you learn to appreciate good use of notation, any notation to decipher the code.

Also while self documenting code style is what you want to try to acheive, it is very important to have a comment that points out the intent of the structure is, not just that it is an if/then construct. Why is this here. It is important to make this decision.

I think James has done an excellent job with this book and I look forward to his next edition.

Dennis

This book might be good for a total novice, but (a) most of the advice in here will already be familiar to VB6 coders (b) some significant areas with major changes from VB6 are completely overlooked (i.e., database), and (c) though this is subjective, some of the advice seems completely wrong-headed (my particular beef: advising against procedure "fan-out", which is one procedure calling many subprocedures. This is in direct contradiction to Martin Fowler's advice in Refactoring, and the key to writing self-commenting code - I'll trust Fowler over Foxall any day).

I bought this book, because I had the VB6 one and was wondering a similar material, but adapted to .NET. If fails short and it's just decorating my desk. The author keeps the same guidelines, for example it recommends using Hungarian when Microsoft guidelines says DO NOT USE IT (even though it's a Microsoft Press book!). Take a look at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp

Those guidelines are more PRACTICAL and useful than this book. And you know what? IT'S FREE!!!

This is a good book for both the experienced and beginning Visual Basic .NET programmer.

The purpose of this book is not to show you how to write a program in VB.NET but to provide a style template on how you should write a program; not only for readability but also for maintainability. To that end Foxall provides many examples of "bad" programming practices and styles along with a suggested "good" one.

The whole argument about using Hungarian notation (HN) or not is really irreverent. The very fact that this book exists and is hopefully read by more than a handful of people means more consistency and more error-free code.

One of the things I appreciate in this book is the use of color (various shades of blue-green) to mark things like comments in code, section headers, etc.

Overall this book was an easy read and can easily be grasped by entry level VB.NET programmers and functional enough for more experienced programmers to reference.

After seeing the author jump in for a review, I decided I would add my two cents into this fray. While I do not agree with the 1 star "slam" that the author set out to counter, I think 3 stars may be pushing it, however.

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.