Customer Reviews

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries

5 star:		(26)
4 star:		(6)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

Depending on your experience with the .NET framework, you may consider the contents of this book as everything from invaluable insights to mildly amusing explanations of a few details of .NET you've always wondered about.

Krzysztof Cwalina and Brad Abrams have worked with designing the public API of the .NET framework from its beginning, and during that process they have compiled a comprehensive guideline for framework design. It is basically this internal guideline they are now publishing as a book.

The text is easy to read and makes for a good reference book. It is littered with more free-form comments from lots of other experts such as Jeffrey Richter, Christopher Brumme, and the occasional comment from Anders Hejlsberg. However, it is mostly reminiscent of a Word document with lots of revision comments liberally sprinkled all over, and I suspect this is how book was made: Take an internal guideline document and polish it off; pass it around to a lot of collegues in Microsoft and ask them to comment on it; incorporate most comments verbatim in the text; and publish.

That said, I still found myself using lots of the little insights in the book in my work in the weeks after having read it. Most of those insights actually came from the free-form comments, so I'm not complaining.

If you use FxCop and are familiar with many of the rules in this tool, most of the guidelines in this book will come as no surprise to you. FxCop was originally a project of Krzysztof's and Brad's designed to automate much of their code review work, so you can learn most of the contents of this book just by using FxCop.

As such, almost all the guidelines in the book are publicly known material, but it's still a well organized reference, and the little extra comments from the authors and lots of other people are what made this book a worthwhile read for me.

I wouldn't consider this book essential reading for .NET developers, but it basically supplements FxCop pretty well.

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.

The new book from Brad Abrams and Krzysztof Cwalina is a must-have book for anyone writing .NET and Mono code.


The book includes many of the design guidelines that Brad's blog is famous for. The book is not just a collection of rules, but it also includes the rationale for some of the design decisions and what really makes the book interesting are the commentaries from other developers and architects involved in .NET.

This book is packed with gems.

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.

I found the book immediately helpful. From the first pages, I was able to apply suggestions to how I designed frameworks. I have been creating .Net libraries since 2002. Now as the Lead Architect, my job is to create an entire product framework from the ground up.

My first decision was to ensure that my team had a set of guidelines. I searched the internet and this book came up on Amazon. I purchased the book, and found it immediately helpful. The authors have hand-on experience writing components of the .Net framework. They have learned through trial and error what works best. This book with some minor additions will serve as the guideline for my team.

You will find the book easy to read, clear and concise. In short the specifications of DO, DO NOT, CONSIDER, helped me understand the best practices for creating frameworks. As I read the guidelines, I also uncovered weakness in my understanding, particularly with the 2.0 framework. In these cases, the guidelines served as a target for additional learning.

I agree with the others, this book is not just for .Net frameworks. These are excellent guidelines for any object oriented language; although the book is directly effective for professionals that use the .Net framework.

Even though this book has ".NET" in the name, it really reaches way beyond .NET and applies equally to Java or any other high-level object oriented language. Also, it is not just architects or designers who should read this book. Every developer trying to understand or even just use any kind of framework will benefit from it and gain deeper understanding why things are built the way they are built. Besides, the time comes in life of every developer when all of a sudden you must write your first framework, a set of base classes or whatever shared piece of code. At this moment you will thank yourself for having read this book (and still having it at reach if possible).

WARNING: this book requires some previous knowledge of object-oriented programming and familiarity with a C-like language (code samples are in C#, but any similar language will do). Also, keep in mind that this book is about design and concepts and not about C# or any particular .NET framework feature (although one can pick up some very useful tips along the way).

This is one of the two books that haven't left my desk ever since I bought them (the other one being "Head First Design Patterns" from Eric and Elisabeth Freeman).

The book is essentially about designing good API based on the lessons learned when designing the .NET Framework. A good knowledge of the CLR is assumed and in particular C#. Most of the examples are in C# syntax with some in VB.NET. The book takes what could be very dry material and makes it more interesting and useful with real examples from the current CLR and anecdotal information from various well known names in the .NET world.

There are 9 chapters and 3 Appendices with information on style conventions, the FxCop tool and a sample API.
The first 7 chapters are well-structured and very readable, even start-to-finish. They can also be easily used as reference material focusing on specifics such as naming guidelines, type and member design and exception class design. The last two chapters cover general usage guidelines and common design patterns. These topics are very broad and consequently the chapters feel more like summary info and don't go into much depth. Picking up some titles from the suggested reading list is definitely recommended to augment these chapters if you are interested in more detail.

Overall the book is readable and straightforward and should help anyone writing .NET libraries produce more usable APIs. Certainly the guidelines are mostly covered by FxCop but the additional information around the 'why' for the rules should help you fix the violations in the right way.

This book is not just for people developing frameworks but also for Application programmers who use frameworks. If you donot know how frameworks are designed then you wont be really efficient in using it.

I also use thier Naming Guidelines in our software development team just to create a standard. Overall a class work. Kudos to Brad et al.

I don't personally think that all developers will find this book useful. In fact, I have a feeling that some may find it highly useless and disruptive as it is abstract in a sense (one must apply the lessons to each library and scenario independently, taking into consideration many different aspects of usability and readability) and it does require some "retraining" of bad practices which have been long since ingrained due to years of usage.

But whether this book deserves a five star rating or a one star rating - whether this book is for you - can be answered by asking yourself the following question: are you obsessed with quality? Quality in the sense of creating a library that is:

- Easily reused by others, even first timers encountering the library or even first timers to .Net
- Well thought out with well designed classes
- Consistent within itself and consistent with the base libraries from Microsoft

The importance of the little things like naming classes, properties, methods, using one type of construct over another, using one type of accessor over another, etc. cannot be stressed enough in the overall picture of creating a library to a higher standard of quality, usability, and extensibility.

As Confucius is to have said:

"If names be not correct, language is not in accordance with the truth of things. If language be not in accordance with the truth of things, affairs cannot be carried on to success.

"When affairs cannot be carried on to success, proprieties and music do not flourish. When proprieties and music do not flourish, punishments will not be properly awarded. When punishments are not properly awarded, the people do not know how to move hand or foot.

"Therefore a superior man considers it necessary that the names he uses may be spoken appropriately, and also that what he speaks may be carried out appropriately. What the superior man requires is just that in his words there may be nothing incorrect."

As I wrote in an e-mail to my team, I think that digesting this book will lead to: higher quality public facing APIs for our customer development teams seeking to extend the functionality, increased readability and more consistency internally in our teams, increased usability and decreased maintenance costs for the support teams as well as new developers on our team, and of course, increased skill, knowledge, and competency as developers of each of the team members.