Customer Reviews

Practical Standards for Microsoft® Visual Basic® .NET (Pro-Developer)

5 star:		(8)
4 star:		(2)
3 star:		(1)
2 star:		(2)
1 star:		(1)

 

 

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.

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.

With a new way of coding VB comes new ways of making the environment more effecient for programmers.

This book is full of good advice about programming practices in the .NET world. The advice is sound and could be even used as an intro since the author goes through great pains to make everthing clear while concise.

Should you follow all the advice? Depends on you. I don't think you should follow anybody's suggestions without some critical thought but the suggestions here are definitely worth taking a look at and debating. VB.NET ain't VB6 and you should not code and organize your code the way you did in VB6. Foxall gives us some good, pratical advice on how to code. More importantly, he gives great advice on how to organize code (something programmers tend to be bad at doing).

The only surprise was the recommendation to use Hungarian notation. I find it amusing that people get so hung up on Hungarian notation (I happen to like it but would not miss it if I never used it again). It's just a way to try to making code more readable when using local variables. If you think it gets in the way, then you shouldn't use it. Other than that confusing suggestion (MS says don't use Hungarian but you ARE free to use or not to use whatever convention you like) the book is flawless.

This is a book that every team doing VB.NET development should discuss if not follow. Standards are important, most of the software building cycle is in testing, debugging and modifying existing code. His standards are something to draw on as we come up with the best practices for our particular solutions.

I felt the need to post my own review after reading the previous one star slam. When I first saw this, I was <stunned>. I've spent far more hours than I care to count researching the information contained in this book, and I couldn't imagine why someone would have such a venomous opinion of this book - which I'm very proud of. Click the name of the reviewer, however, to see his/her other reviews and you will find that they dole out 1 star reviews to most of the books they read - can't imagine why they'd continue to purchase books with so many terrible experiences

This book contains a wealth of information culled from many sources and professional experience. Take a look at the reviews for my other books and you will find that I write high-quality books for professional developers. The Hungarian notation presented <does not> conflict with the .NET philosophy, due to the fact that I recommend that Hungarian stay internal to your objects so that your object names and interfaces remain "hungarian free". (In fact, I state the Hungarian is completely optional, but that I and others still feel it has a place). Af far as the content on modules, most of the material is equally applicable to classes. Rather than discuss the material in two places (modules and classes), it is presented in modules first (the easiest to grasp) and the material on classes then builds upon the previous subject matter.

Obviously, the previous reviewer "just doesn't get it".

At any rate, check out the sample chapter or send me an email with questions and I'll do what I can to help...

James

I was a fan of Foxall's Standards book for Visual Basic released a few years ago. James has done his usual good job on this book. Visual Basic .NET represents a very new way of development, and I have been using it for almost 2 years in beta form. Now that VB.NET has shipped, this book is an invaluable guide to how to do things right. Other books will teach you about the technical aspects of programming in .NET, but this one tells you how to do it correctly in a standardized environment.

Take the negative review (below) for this book with a grain of salt. The writer hounds the book for taking on the subject of naming conventions and hungarian notation. Hungarian is a personal issue and you have to decide for yourself as to its applicability in .NET--a point that Foxall takes pains to point out.

Regarding modules, they have a place in VB.NET, and it makes sense in a standards book to address them first, so that they can later be compared to classes. It is interesting to note that the first reviewer's list of computer book reviews on Amazon is almost universally negative--he gives 1 star to almost all the books.

If you are looking to do professional development with Visual Basic .NET--this book should be required reading. While you may not agree with every standard proposed, it will get you thinking about how you should use standards to reduce development and maintenance time on projects.

I have always been passionate about code conventions and standards. In my early VB days I was weaned on the likes of Stan Leszynski, Greg Reddick, and James Foxall. As I began to investigate moving from the VB6 world to the new .Net landscape, I was eager to find out what James Foxall would think. Especially since he had always been a strong advocate of Hungarian Naming conventions, and the new sounds out of Redmond were recommending against them.

James finds the perfect balance, maintaining the true spirit of the Design Guidelines for Class Library Developers found in the .Net Framework documents. The point of the non-Hungarian recommendation is "to encourage consistency and predictability in public APIs while enabling Web and cross-language integration." Of course conventions tied to a particular language's type terminology do not belong on the public interfaces of class libraries. Peter Vogel said as much in the VB6 days with his Object and Component title. (Looking forward to that VB.Net edition, Peter!) But for those who find HN a useful tool, they can still utilize it on the interior of their objects, and remain completely compliant with the .Net docs.

Outside this often "thorny" question, the rest of the book is as rock solid as ever, providing guidance and direction on everything from how best to design solutions, projects, and classes, to commenting code and laying out flow constructs. You may not agree with absolutely every recommendation, but you will be hard pressed to find anywhere a more complete standards guide for the .Net platform. Even if you choose not to utilize Hungarian Naming standards, you can benefit greatly from the other code suggestions James provides. It would be a pity to let that one aspect of code conventions prevent you from gleaning from the richness here.

Outside of all this, I have to say that James Foxall is one of the most personable developers I have had the pleasure to encounter. When I was seeking information on where to go with .Net, I contacted him directly because I couldn't wait for the book's release. He was most responsive to my questions, and helped me work through just what to think while moving to .Net. This one is on my desk to stay!

You will benefit greatly from giving it a read!

Kel

No book on coding style and standards,can be the bible for every programmer alive. Usually, reading these books helps us decide what we do wrong, what is a better practice and what we do not like. Experienced programmers may adopt fewer recommendations from the book than less experienced ones.
From this point of view this book can be invaluable to every open-minded developer. You can build on it and have your own standards in no time.
I believe the attack and the single star rating by "geek" is totally unjust, based on a zealot's attitute against Hungarian notation. In "Design Guidelines for Class Library Developers", under "Naming Guidelines" .NET team gives its suggestions on naming Namespaces, Classes, Interfaces, Methods, Properties etc. To geek's surprise .NET team RECOMMENDS Hungarian Notation for Static Fields!
The Author of this book has a whole chapter "When Not to use Hungarian Notation" whickh agrees 100% with .NET guidelines.
I gave it only 4 stars because it does not include a CD with the electronic version of the book(many other MSPress books do) and I had to do a lot of typing to make my own standards for my team.
Microsoft and James give us the e-book!

I had read the first edition of this book and really liked it. This new edition is a definite improvement of that other book. Unlike some .NET titles which seem to be a rehash of VB6 code, this book has been truly updated to .NET. Not only does it teach you the best way to do things, you'll also learn some new programming techniques as well because Visual basic.NET is so different from VB 6. The chapter on using the new exception handling was an eye opener. The new chapter on programming objects was a much needed edition to the book and could probably be expanded even more. The distribution chapter has a great checklist that EVERYONE should follow before shipping a product.

all in all, a GREAT book! Oh, a bonus is the new edition is hard cover, which is awesome because you use this book as a reference a lot and the paperback edition wouldn't take the abuse as well.

At any one time I am typically supervising five or six .Net developers. For Web development, the two most obvious choices are C# and VB.Net. Every good developer I have met says C# is a better language. Nevertheless, in general I have my developers use VB.Net. Why? Because I can read VB and because of this book.

A book of standards is really really important. "Code Complete" by Steve McConnell is clearly the best book on the subject ever published. McConnell is simply in a different league. But McConnell's book is not oriented to any one language, and it helps to have a language specific book.

So after my developers read Code Complete, I have them read Practical Standards. It is an excellent and comprehensive book. About 98 percent of it I agree with. Even if you don't, it is clear that Foxall has carefully thought about his choices and is articulate in explaining why he prefers a certain approach.

I think every VB.Net development team should buy a copy for every developer, made them read it, and then make them follow it. Have regular code reviews and point out when they have deviated from these standards.

If you are managing a team of VB developers, and then are a few areas where you disagree with Foxall, then simply write a memo. "Follow Foxall except in the following cases, where you should do the following ..." I cannot imagine that one would not want to follow his standards almost all of the time.

I would rather go with C# but I am aware of no similar book. There are lots of good C# books but none that are just standards book. Why on earth does Microsoft Press not publish an equivalent book for C#.

[...]

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