This is very much guide to best practise in your dev team. It will help any team and sure helped mine.
Its easy to absorbe and it makes a different.
It can also be dipped into when you need 'advice' and for us was a first port of call when we were setting up best practise in our department.
Might be one to get second hand and ensure that it circulates in your department.

As a compendium, making for efficient reading, among the best. Definitely one of my fire exit books. Can't wait for the sequel for .Net 2.0/3.x.
Congratulations to the authors for winning an Excellence Award from the Society of Technical Communication.

This book was referred to me by a friend that is a very talented developer. I now see why he keeps this text on his desk while developing. The author provides excellent code examples in multiple languages. This is one of the best books that I have purchased in years !

John Robbins on the foreword of this book wrote "..No matter how you use Practical Guidelines and Best Practices, it will save you a tremendous
amount of time by helping to reduce those insidious bugs and performance problems in your
code. I've been using it with all my projects, and it's certainly made me a much better developer.."

I'm a simple .Net developer, how can i say more, from when i bought this book it is ever on my desk like the Holly Bible.

I had the honor of met both Francesco Balena and Giuseppe Dimauro it was like a normal violinist could talk with two Paganini.

In the [...] environment there are many different ways to accomplish the same result. This book provides information from people who are indisputably knowledgeable in the area that helps enormously in choosing between the various options. One of the most useful parts of it is the explanation that is provided for why one option has been chosen above another, which is to say, why it's a "best practice." I would recommend this book to any .Net programmer who wants to acquire concrete data that will help him in making his programming decisions.

Although there are some good insights here and there, not too much to gain.

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.

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.

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.

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.

My name is Turki Al-Aseeri and I'm a well known developer here in Arabs countries. I'm from Saudi Arabia which is far away from Italy. So Mr. Balena doesn't know me and have no idea about me.

I just would say one thing about this man: Because of his fantastic books, I've been named recently as Microsoft Most Valuable Professional MVP !!!


Mr. Balena,
You will be the greatest book author and the most respected one that I've been ever know. All of your valuable books are set on my desk and I'm dieing to read your coming one on VB2005.

I would say to you: Just move and keep on your work. For those misleading comments, you would ignore guys who envy you!!

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.

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?

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

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.

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.

This is an excellent book that helped me improve my skills and saved me a lot of time.

The reviewer who rated it 1 star either had a bone to pick or he doesn't understand .NET whatsoever.

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.