Book Review: Framework Design Guidelines

I originally came across a title Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries after perusing the documentation on the Subtext site.

For the most part, I had been following the guidelines outlined by Scott Bellware in his handy dandy style guide, but this text – FDG – takes it to another level and formalizes it in a way that it must be accepted by development teams since it was born from the source itself: the .NET Framework development teams.

I’ve reviewed it on Amazon, but here is the transcripted text:

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.

The title of this book is perhaps a bit misleading.  In reality, this book is applicable for anyone doing .Net development since it will lead to better quality code construction irregardless of whether you happen to be working on a “framework”.  What I also like about the book is that the authors, architects, and various developers who worked on the .NET Framework admit error and inconsistency in some design and shows that this book is truly a work of the men in the trenches and intended for those of us who work on the front line of software development.

While the book does not delve into architecture or design, I think it still has value in enhancing the skill and mastery of any developer that takes the time to read it.  Definitely pick up this book if you are serious about becoming a better developer in the sense of being a more refined craftsman.