Under duress, Brad Abrams recently posted a set of internal coding guidelines to his blog, meant mainly to be a "tie-breaker" in the holy war type arguments that result from seasoned developers who love their own coding styles. I'm a big fan of the work Brad and his team have done on the CLR and their focus on consistency in the API. And, even though there are one or two I don't care for, I'm a huge supporter/follower of the design guidelines.  That's why I was surprised at how many of the internal guidelines I disagreed with.  Roughly 50% of them made me recoil in horror.  Of course, now I understand why I don't like the Visual Studio defaults.  I won't get into which ones I like/dislike because that's not a productive area of discussion.

Now that I've had a couple of days to let them sink in, I realize why Brad was reluctant to share them.  I think they may cause more controversy than solve.  The big questions is how useful will these be in helping my team be more productive?  At this point, I don't think much.  I think we'll stick to the public API guidelines and use the somewhat informal guidelines our team has created for the internal stuff.