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

Framework Design Guidelines, Second Edition

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 (9)
  1. Jonathan Allen says:

    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.

  2. Jonathan Allen says:

    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.

  3. Lothan says:

    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?

  4. Marco says:

    please don’t forget the VB.NET developers 😉

  5. jomba says:

    Please forget the vb .net developers 🙂

  6. *Naming conventions for Unit Test methods

  7. Brad says:

    Making your components friendly to logging and monitoring.  I like to sprinkle my libraries with Trace writes via a designated TraceSwitch.  If the client is interested in logging this information for diagnostics purposes, he can enable it from his config file.  I’ve also been considering putting performance counters in my libraries (like Enterprise Library does).  What would you have to say about this space?

    Any guidance on libraries that have a configuration presence.  Many of the libraries I write can be configured through the config file or programmatically.  This can get confusing, though, if you expose a property through configuration, getter/setter, and perhaps even in a method argument.  I build the configuration portion of my libraries using Enterprise Library so that developers can configure my libraries with the EntLib configuration tool.  Smart or dumb?

    Practical guidance on package, deploy, patching, versioning, and deprecation.  I try to give the appearance of some professionalism to my components by packaging the binaries, source, and documentation in a single MSI (using WiX).  In order to be quasi-backward compatible, every new release includes the binaries, source, and documentation of the previous releases–we only break with that tradition when we move to a new CLR version (like the move from .NET 1.1 to 2.0).  For patches and bug fixes, we usually just push out a zip with the new binaries, but I’d like to into Windows Installer patching (MSPs) in the future.  Any discussion in this area would be nice.

  8. Lee Campbell says:

    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.

  9. Erik Wynne Stepp says:

    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.

Comments are closed.

Skip to main content