Author: Krzysztof Cwalina and Brad Abrams
Publisher: Addison Wesley; 2nd edition, 2008
Aimed at: experienced .NET programmers
Pros: Insightful and fun to read
Cons: Rather a lot to take in
Reviewed by: Mike James
Framework Design Guidelines is the sort of book where programmers sit around and talk about what to call a variable and how to capitalise its name. Don't get me wrong this is all interesting and vital stuff but as you work your way through nearly 500 pages of similar, often microscopic, concerns you start to lose your sense of reality.
The basic format of the book is also a little strange. It has a main narrative written by the authors - although it seems to the reader to be a single voice. Then there are comments from various luminaries scattered around in grey boxes. Each box is attributed with the authors name in a prominent place and often the author of one comment will refer to the comment made by another - as if it was a conversation.
Often the comments will take issue with the guidelines described in the main text and then another comment will take issue with the comment and so on. It all makes the book easier to read and it enlightens you that in the world of design guidelines things are not as prescriptive as you might think. It does help to explain the "why" and not just the "do".
It also serves to give you an insight into how Microsoft built various bits of the .NET Framework. Often a comment will say "we did it this way and I wish we had done it another way". Having the bad choices revealed to you is both educational and slightly fun.
Going beyond simple naming rules and targets in framework design, the book also examines the various patterns that you are likely to need as you implement a framework. This is at the level of how to deal with object lifetime problems using interfaces such as IDisposable. The book covers aggregating components. the async pattern, dependency properties, dispose pattern, factories and the various mechanisms introduced to enable LINQ to work.
This part of the book is interesting enough to be spun off into a separate volume if the authors could identify the much larger number of patterns that occur in practice - Ifreezable, ISupportInitilize and so on. When you think about the number of patterns you encounter when using a framework, let alone implementing one, you start to think that this is an underdeveloped part of the book.
A final appendix deals with FxCop, which can be used to enforce many of the style and coding rules discussed in this book. This is clearly the right way to do the job but it is important to note that many of the aims and aspirations discussed in this book are at too high a level to be translated into simple style rules. This book isn't just a set of FxCop rules introduced at length.
There is a DVD bound into the back that contains training sessions and example API specifications.
If you are working on any reusable components or classes then you should probably read this book. It isn't essential reading in that it won't help you implement your masterpiece and you probably won't learn anything new about C# or object-oriented practice from it. It will however make you think about how you present your code to the outside world and set a standard of ease of use and consistency that you should strive for.
Recommended to any .NET programmer involved in creating code for public reuse or just wanting to make their code as good as possible.