What do you want to see in the second edition of Framework Design Guidelines?

Krzysztof and Brad have announced they are working on the second edition of the awesome Framework Design Guidelines and are looking for feedback on what they should put in it. For those that don't know, a lot of our Code Analysis rules are based on the writings in this great book, so expect to see additional rules in the future based on the new guidelines in the second edition.  To provide feedback, head over to Krzysztof's blog and post a comment.

Comments

• Anonymous
  January 15, 2008
  I would like to see better guidance on Disposable classes. Too often we see classes like DataTable that appear as though they don't really need to be disposed, but there is no way to know for sure.

• Anonymous
  January 15, 2008
  I have a lot of libraries containing user controls and forms that should be inherited. But I don't see any guidance on the best way to expose child controls on base-class forms and user controls. Should they be marked protected? Should they be hidden entirely and exposed via properties on the control/form? What are the naming conventions? I just don't know.

• Anonymous
  January 15, 2008
  I would like to see more consistency in the standards and fewer quotes that detract from the content. Quotes can add useful information to the primary content, but there were so many I questioned whether the purpose was to publish guidelines or to publish an open forum that questioned the validity and applicability of these guidelines. As a result, I left the first edition sitting on the shelf of the bookstore and linked to "Design Guidelines for Class Library Developers on MSDN (more meat, less sideline commentary). For additional guidelines, I would like to see these areas covered:

• Clarify field naming conventions from parameter naming conventions when the guidelines result in name clashes. As an example, constructors often accept parameters that are simple assignments to private fields and these names often clash (e.g. this.firstName = firstName).

• When performing assignments to property-backed fields, is it preferable to assign the value to the field directly or to assign the value to the property and let the property assign the value to the field?

• If the preference is to assign values to the property, how is this guideline affected when these properties must be virtual (e.g. for NHibnerate domain classes)?

• What is the preferred naming convention for controls on a form? Are controls really just private fields or are they special cases in some way?

• Anonymous
  January 15, 2008
  please don't forget the VB.NET developers ;-)

• Anonymous
  January 16, 2008
  Please forget the vb .net developers :-)

• Anonymous
  January 17, 2008
  *Naming conventions for Unit Test methods

• Anonymous
  January 17, 2008
  The comment has been removed

• Anonymous
  February 28, 2008
  My first comment would be: "the book plus the DVD was brilliant. Combined with FxCop I believe that my code (and anyone else who wishes to subscribe to the guidelines) is far more consistent, durable, secure and hopefully a touch better performing". It would be nice to see if the teams responsible for emerging technologies such as WPF, WCF, LINQ, TPL etc provided rule sets for their technologies. It has taken me approximately 10 months to become sufficiently proficient in WPF to set in house standards which I have then attempted to translate in to our own WPF FxCop rules. I would be lot more at comfort if these rules came from some one from "Redmond" instead of my best effort.

• Anonymous
  March 19, 2008
  There are a lot of language changes in both C# 3.0 and VB9.  Some of these new features are potentially confusing if abused and could led to difficult to maintain code. Even Anders Hejlsberg discourages developers from using some of them too liberally. Some guidance on when it is good and appropriate to use these new features, and when it is discouraged would be useful.