Software Architecture, Agility & .NET

My Beef With MSDN Library and the Microsoft SDKs

As much as I love the MSDN Library, and as much as I am very much impressed with Microsoft's efforts to provide us architects and developers with as much support as they can -- much more than any other development tools vendor --, I have some issues with the MSDN Library and the SDKs that Microsoft provides.
        Don't get me wrong, I don't hate Microsoft--hey, I used to work for the company and I still love it. So don't bash me for bashing Microsoft. At least not today.

I just think Microsoft, as a provider of the platform, the tools and much of the technical resources that go with them, has a responsibility to teach the architects and developers who work on their platform how to do it right. And, even with all the richness that's in MSDN, in some areas they fall short of that. Many code samples in the Library and the SDKs use, well, Worst Practices.

A couple of examples to illustrate:

• ASP.NET Pages that access the database directly. This is a very bad example, while at the same time the company (and especially its consulting division, Microsoft Consulting Services) is trying to evangelize N-Tier Design;
• VB6 code in VB.NET Samples. No, we shouldn't be using CInt() and Left$ anymore, thank you, they are not O-O but imperative functions. I understand that Microsoft provided these methods into the Microsoft.VisualBasic namespace so that VB6 developers wouldn't feel left out, but the reality of it is that developers who used to work in VB6 continue to use their old habits, even if .Net is a totally different environment. But how are VB.NET developers supposed to know they need to use Convert.ToInt32() and string.Substring() instead if their VB6 counterparts are found in so many examples? Especially if the documentation encourages old-style VB6?
• .Net Naming Conventions as described in the .Net Framework Design Guidelines and enforced by FxCop: these rules are violated by MSDN Library code examples almost everywhere. There are namespaces with underscores in their names, identifiers with 3 or more capitals in a row or--can you believe it?--Hungarian notation and "m" prefixes for member variables;
• Use of public fields rather than properties. This goes hand-in-hand with the violation of naming conventions and the fact that "property" values cannot be validated and are thus always assumed right;
• The Exception constructor documentation gives an example of how to implement custom exceptions--but they derive from System.Exception rather than the recommended ApplicationException or even the base exception found in the Exception Management Application Block.

I think the issue is, basically, that MSDN doesn't enforce coding conventions or even naming conventions in their examples. This is strange because these are the lowest-hanging fruit in the Best Practices Tree and MSDN, by its very nature, should lead by example (right...?)

So, a request for the MSDN Team and the team program managers responsible for the SDKs: please, please, pretty please, can you create a set of coding conventions and stick to them, as well as to the "standard" Fx naming conventions? Can you please make these public and make sure that all contributors to MSDN, worldwide, stick to them? Please use your influence not just to get more architects and developers onto the platform, but also to make them create better, more robust, more maintainable applications.

Many thanks in advance!!

Man, I can't tell you how good it feels to finally get that off my chest!