I recently picked up a copy of “Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries” by Krzysztof Cwalina and Brad Abrams.  This is a great find; I’ve never picked up a hard cover book from the Microsoft .NET Development Series (Addison-Wesley Professional) that didn’t rock and belong in my library at home. 

As I’ve been working recently on a new test framework library (while reusing a lot of existing components), the release of this book couldn’t have come at a better time.   We all know there’s no silver bullet, and this book doesn’t try to pretend there is one-Krzysztof and Brad make it very clear that there still aren’t any perfect answers.  A lot of decisions depend on your framework consumer.

The book is organized much like a Microsoft specification or guidelines document is; you’ll find helpful bullets designated all the way from “DO” to “CONSIDER” and “DO NOT,” among others.

Some of the key takeaways that I have:

• Keep it simple. Design with your customer in mind, and don’t get carried away with creating a framework worthy of a prize in perfection of theory
• Capitalization of your public methods is really important to creating a self-documenting framework that users are comfortable with immediately. I still cannot believe there’s so much contention in naming in the .NET platform even today.
• There’s no need to go virtual method happy with overloads; you often can provide your most specific overload the virtual designation
• Good reasoning and comments revolving around some classic situations: Array or Collection as a return type? String or Uri?

There are also some good resources near the back of the book, such as a starting point for your own coding conventions that take into account the implementation specifics and private code in your framework.

And I do have to point out one thing: The book format is truly unique for a reference that is 300+ pages.  “Framework Design Guidelines” is effectively a massive bulleted manuscript, full of inline comments.  I enjoyed this format, it really helped to bring home that these are suggestions, not solid rules; the arguments and points for- and against- were borderline fun, as were anecdotes about earlier .NET framework releases.

The reason I point out this unique format is that it is truly a Microsoft creation by two brilliant Microsofties: I can just imagine the Microsoft Word file that was used for collaborating between the annotators, and it is pretty fun seeing a book in print that roughly aligns with the “Final Showing Markup” reviewing mode of Word 2007.

2 Comments