Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# Developers [Paperback]

I think Amazon readers should know the true story behind the "Don't Waste Your Time or Money" review by Alex Papadimoulis.

The review in question was excerpted from a post in Mr. Papadimoulis's own blog. After I replied to his original post, Mr. Papadimoulis corrected some of his affirmations and admitted that his original comments were too harsh. (Quite unfairly, he didn't edit his Amazon review, though.) His review was so biased and groundless that many of his own readers complained and proved him wrong on many points.

CREDIBILITY: We authors never claimed we are in the same league as legendary scientists such as Knuth and Yourdon, but fortunately there are several degrees of credibility. Each of us has 20 years of experience writing real-world successful software apps, we work with .NET since earlier pre-beta versions, we consult for Microsoft and writes code for their largest customers in Italy. I have written nearly one hundred technical articles on magazines such as Visual Studio Magazine and MSDN Magazine, spoken at many .NET conferences in US and Europe, and authored several books (some of which are currently used in US schools and universities).

MSDN Regional Directors aren't volunteers, as Mr. Papadimoulis incorrectly writes. RDs are carefully chosen by Microsoft Corp. among the best .NET experts with the highest reputation. In fact, there are only 140 RDs in the world and we are very proud to be in this restricted group of experts. Mr. Papadimoulis's deliberate attempt to reduce the value of the RD status is representative of how biased he is.

THE "RIGHT" WORDS: Words such as "Do", "Don't", "Always", "Never", "Right", "Wrong" etc. are customary in guideline books and articles and Mr. Papadimoulis knows it, but he apparently forgets this detail in the attempt to make readers think we're unreliable. At the very least, he should reckon that we clearly state that our guidelines shouldn't be considered as valid in all cases, mention that we always explain WHY a guideline is recommended and that we often provide alternative rules and exceptions. Our book is about *practical* guidelines and our rules are much less rigid than what Mr. Papadimoulis maintains.

SPEED VS MAINTAINABILITY: Most of the examples that Mr. Papadimoulis provides are related to two contrasting techniques, for example the "as" operator vs. "is operator + casting" or "Compare" vs. "CompareOrdinal" method. It's important to notice that in all cases *both* techniques are simple to maintain and *both* are fully documented, thus recommending the faster one has no drawbacks whatsoever. (We never met a developer that would prefer to use a slow technique if there is an alternative.) Nowhere in our book do we suggest a faster technique that hampers maintainability or that is based on undocumented features.

THE THREADABORT EXCEPTION: Our guideline states that you should never catch this exception but that, if you really need to catch this exception, you should rethrow it immediately because the application can be in unstable and unrecoverable state. Our rule isn't rigid and is fully compatible with what Mr. Papadimoulis describes about cleaning up from a background thread. He either read that guideline too hurriedly or purposely omitted the exact text, in the attempt to make it look arbitrary. In either case his behavior as a reviewer is rather questionable, to say the least.

MSDN RECOMMENDATIONS: Ironically, *all* the guidelines that Mr. Papadimoulis considers as questionable are recommended by Microsoft in several MSDN articles. In other words, Mr. Papadimoulis is convinced that he knows the .NET Framework better than those who created it! I publicly asked Mr. Papadimoulis to explain this laughable contradiction but, understandably, he decided not to reply.

RELATIONAL DATABASE THEORY: I have a Computer Science degree and I am aware that Codd recommended using primary keys that have a meaning for the application. However, he did so 30 years ago, when there were no databases distributed over WANs or the Internet. This is where a book on *practical* guidelines differs from textbooks that are mostly theoretical.

The truth is, applying Codd's rules to ADO.NET and disconnected databases is often unpractical or even impossible. Even not counting ADO.NET and disconnected databases, many database experts (including Microsoft gurus) recommend using meaningless primary keys stored in 32-bit or 64-bit integer fields because they are *much* faster. This is one of the reasons why SQL Server and virtually all modern databases support primary keys of this kind. Or perhaps is Mr. Papadimoulis suggesting that we should ban these databases just because they don't religiously follow Codd's theory? <g>

I could continue with other examples on how inconsistent his criticisms are. If you are interested, you can read the entire story - his first and second post, and my replies to both - by googling for "Papadimoulis blog Balena".

There are few books out there that cover what is sometimes a vague and subjective topic in such a straigtforward and clear manner. I'm always looking for consistent guidelines when constructing code.

No sensible person (ahem, Mr. Papadimoulis) would read this book feeling as though the authors were trying to set their practices in stone. The word "guidelines" is part of the title! Most of the guidelines are accompanied with clear explanations and sometimes exceptions to the rule.

Also, if I may nit-pick for a moment, Papadimoulis (a previous reviewer) states that in the book "they use a class named 'frmMain.'" which is inconsistent with the MSDN. Technically, this is a parameter name that refers to an instance and not the name of a class. I wouldn't even mention this if it were not such a beginner mistake. Especially since the naming guidelines are different.

It is a much more demanding job to write a book about „how to do things" than about „what you can do". Overall the authors did an excellent job.

Most recommendations are very practical and can easily be applied immediately. In addition many of the suggestions are put in context with a brief discussion over the pros and cons. But people looking for thorough academic debate on any theme will be disappointed. The book is tailored towards practicality. It is simply structured, uses basic and direct language and takes clear positions. That makes it easy and fun to read - yet it provides remarkably good information, not primarily on grand concepts, but on many small things that often get overlooked.

It is the kind of book you take where ever you go when you just have a couple minutes to read. Open a random page and always get a little "aha".

› Go to Amazon.com to see all 21 reviews  4.7 out of 5 stars