I bought the last copy of Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams at the PDC so that I’d have something interesting to read on the trip home, and I was not disappointed. I find myself in agreement with nearly all of the guidelines; widespread adherence to them even when writing small libraries would improve overall code quality. Of course, it’s much more interesting to highlight the areas that I don’t agree with, so I’ll first make myself clear – I highly recommend this book to anyone writing code that uses the .NET Framework or any similar object-oriented framework.

One classic source of disagreement is in the use of Hungarian notation; I use a mild form of that notation that I feel greatly improves code readability. The guidelines only prohibit the use of these identifier “warts” on the public API, which would be fine, except that method parameter names are shared by the API (which shouldn’t use them) and the implementation (which should, if the rest of the implementation does). So, what to do? Since there’s no easy way to have my cake and eat it too, I just use Hungarian with parameter names, and hope that my clients will forgive me.

I’m not fond of the event pattern where a protected virtual method is defined that raises the event. It’s not clear to me why derived classes should be able to suppress the raising of events; I prefer virtual methods to always be abstract or empty, so that derived classes don’t have to call the base-class implementation at all. I like adding the virtual method, so that derived classes don’t have to add event handlers to their own events, but I tend to call the virtual method and then raise the event.

Speaking of parameter naming, and speaking of events, I really don’t like the convention of calling the EventArgs parameter e. I use args.

Finally, I only agree with about half of the coding style conventions listed in Appendix A:

• They seem to have something against spaces, which are important for readability, particularly if you’re using a proportionally spaced font. (You really should be writing code in Verdana 8pt if you’re not already.)
• I love omitting braces around single statements; I don’t buy the “readability and maintainability” argument, particularly when you put the opening brace on its own line (which they don’t).
• Tabs are way better for indentation than spaces.
• I’ve never understood why private fields should go at the top of a class declaration. All other private members go at the bottom, and for good reason; why not fields? Otherwise, their recommendation to group members is good, though I prefer logical ordering to alphabetical ordering when practical.

I’ll have to publish my own coding style conventions one day. If you’re really curious, just look at code samples elsewhere on this blog…

And in case you skipped down to the bottom, let me reiterate – you should read this book!