Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries [With CDROM]

At Microsoft I work on a development team that has been using the guidelines from this book for nearly 4 years. I am not always a fan of coding standards, thinking they are a necessary evil, often simply arbitrary choices made for consistency. The Framework Design Guidelines are different. These ensure deep consistency across not just source code, but more importantly the public classes themselves. They include critical, not to be ignored rules on security, cross-language access and localization, as well as the usual good practice type guidelines. But even these "good" practices are always backed with well reasoned argument and examples. As an added bonus FxCop provides a static analysis tool that enforces the guidelines. Finally, the Framework Design Guidelines provide deep insight into how the .NET Frameworks are designed and used. With the guidelines in mind it is far easier to remember or even guess what classes are provided and how they should be used. This just makes the libraries that much more productive. Full disclosure: I know Brad and Krzysztof personally, but I would simply remain silent if I didn't think highly of the work.

This book was written by *the* two Microsoft experts on design guidelines for the .NET Framework: Brad Abrams and Krzysztof Cwalina. It really is a MUST read for anybody designing OO class libraries especially libraries that are based on managed code (aka .NET Framework). What I really like is that there are not only "Do", "Do Not", "Avoid", "Consider" guidelines but most of the guidelines are accompanied by annotations from many different folks (Jeff Richter, Rico Mariani, Chris Brumme, Chris Sells, Brent Rector, etc). These annotations really help with the pragmatic side of deciding between conflicting forces. That is, there are many guidelines where you could go one way versus another. The annotations serve to help you decide which way to go. I give it two thumbs way up and even thought it's about 300 pages, it is a quick read.

The title I chose for this review is no cliché. This book earns each and every penny you spend (or have already spent) on it. I was deceived into thinking that the book was the work of only Cwalina and Abrams and that it's merely a rehash of FxCop guidelines that we have already known and been using for a while now until I read book and encountered the annotations. To have .NET gods (dare I say) like Richter and Hejlsberg contributing suggestions (whether you already knew them or not) in the same book along with other greats like Mariani, Gunnerson, Chris Sells, and Paul Vick to name just a few is simply a slam dunk. One myth about the book is that it's only useful for folks building APIs. That is so far away from the truth. This book "should" be read by both .NET architects and developers. The suggestions and tips presented in this book can help you write better and more efficient and re-usable code whether it is for a little program or a class library. And if all this book material was not enough to quench your thirst, the book comes with a bonus: a DVD containing video presentations and seminars on topics related to the book's material (Rico Mariani's presentation is a must see), a sample "real-life" API specification example for the .NET Framework 2.0's System.Diagnostics.StopWatch class, and a .NET 2.0 tool with source code that can be helpful in code reviewing API classes (even though it still has some minor bugs). This book contains a wealth of material in so small a book and so easy a read that it won't take you too long to read. If you are like me, you would not be able to let go of it before finishing it. The only take I have on this book is that it should have been available a long time ago, probably when .NET 1.0 was shipped out (blame Microsoft?). It would have helped prevent all the .NET spaghetti that we still see these days. If this book ever gets any negative reviews, they would probably come from either someone clueless or from someone utterly jealous. It would be naïve to think of this as just a book. Get it, read it, and you'll see for yourself what I mean.