Customer Reviews

Practical Guidelines and Best Practices for Microsoft Visual Basic and Visual C# Developers (Pro-Developer)

5 star:		(18)
4 star:		(1)
3 star:		(1)
2 star:		(0)
1 star:		(1)

 

 

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".

Most of the time there are at least two, if not two dozen ways to implement something in software. Following some sort of guidelines makes it easier to go back and look at old code that needs modifying or fixing. In this book the authors attempt to define a set of standards to be used in their company and suggest that these be the standards used worldwide.

The book starts off very simply, i.e. where to save the files you are creating. By the end of the book in the security chapter the hints and tips get more complex.

This is an intermediate level book. It is intended for the programmer who knows the language but is moving up to bigger projects. As with all of us, the authors have experience in various programming environments other than VB and C#. Sometimes these experiences come out in the form of a Practical Guideline that might not be the best way to do something. Your own experience will likewise lead you to programming methods that may differ from their Guidelines.

On the whole, any programmer reading this book will come away with some guidelines of the "Gee, why didn't I think of that," variety.

This is a phenomenal investment. I now use it when ever I start a new section of code.

Just as the title implies - the authors give you guidelines for each step of the software development stage. It has made my code run faster and smoother and I get so many compliments on how "clean" my coding style is now.

Even if you've been programming for 20 years - or are about to start on your first project BUY THIS BOOK. It is a fabulous tool.

In addition to the Knuth and McConnell books it is nice to have a pratical guide on your desk as well. DiMauro and Balena's reputation precede them and it is easy to see why. There are a number of really useful gems in this book. As with any book with a breadth and scope as large as this one, not every practice is applicable to every situation, and I think they do a good job of telling when a particular piece of advice appliies and when it doesn't. More importantly for me, I found that they were very good at giving me advice on how to think about the problem and solutions domains. All in all, a great job with a very difficult subject.

I am a reader of Balena's books and appreciate his writings. I have read this book and would only say that the objective of the book if not teaching theory to computer science students but to explain practical guidelines.
I am a computer engineering graduate myself and have studied both thoery as well as working on cutting edge technologies for past 7 years.
There are times where most of the theories are not in line with the practical development life cycle and I have seen best of the architects breaking Mr Codds rule on database most of the times.

This book is one such master piece that gives you information on real world development guidelines and best practices and have recommended this book to most of the fresh developers in my team.

- Techie

I was driven to buy this book by the negative review of Papadimoulis. I now have the book in my hand, and I haven't been able to put it down.

So far, I haven't seen any recommendations I disagree with. It's actually entertaining to explore the book and discover several tips that I did not really know about. Even the seemingly simple {_string == ""} being slower than {_string.length == 0} was a pleasant surprise.

That elegant and really simple snippet for providing asyncronous support is worth the money I paid for this book. I can already imagine many team mates casually coming by my desk, picking up this book, rifling through absent-mindedly and then suddenly ... wide-eyed with amazement because they just stumbled across a gem.

The author of this review says :
"It would also appear that the authors have little to no knowledge of relational database design. On page 380 they say "Don't use primary keys that have meaning for the end user, such as invoice number or the ISBN value." This is beyond absurd and defeats the whole purpose of "relational databases. Don't take my word for it, of course; ask any "Database 101" student or read it straight from the creators of relational databases (EF Codd and CJ Date). The authors' technique is as close to a COBOL-mainframe-flatfile method of development you can possibly get and is, ironically, what relational databases were designed to fix."

I wonder where this guy has been living and working in these last years .. did he ever draw a database in the real-world ? Putting application meaningfull fields in a Primary key is the way taking you right to a maintenance and application evolution nightmare (not to talk about performance issues on joints). In my opinion, this is exactly the mistake most people do once or twice in their programming career (.. at the beginning of the career I mean :)) .. Don't know how this guy can be so angry to write such "questionable" things without reading them once or twice before hitting the submit button.

This book has great stuff in it. However, it starts off really slow and might tempt you to skip it. Don't! There is a ton of information for many areas of development. I especially like having both VB and C# and their differences noted. This can be used at any level, but the more experienced reader will value the wealth of knowledge even more.