Jelle Druyts

During the pre-conference session on Framework Design Guidelines, Brad Abrams was kind enough to share the story behind the infamous HasShutdownStarted property on the Environment class with us. If you're unfamiliar with that property, take a look at its original definition below:

public sealed class Environment
{
  private Environment() {}
  public bool HasShutDownStarted { get { /*...*/ } }
}

Now see if you can spot the "minor issue" with this property...

The funny thing is, this code actually shipped in the initial release of the .NET Framework, but obviously it needed to be QFE'd (Quick Fix Engineered). So Brad did a little investigation to see how it could have happened that an effectively uncallable property made it into the framework. Running through the engineering callstack, he found out that:

• The property was implemented and unit tested by the developer.
• It was subsequently tested and approved by the tester.
• It was documented along with "working" sample code.
• And finally it was reviewed and accepted by the Program Manager who owned the feature (in his defense, he had originally specified that it should be static).

According to the story, this incident triggered the static classes feature that is new in C# 2.0 (which declares a class as having only static members) to prevent this from happening again.

By the way, declaring a class as static makes the compiler mark the class both sealed (so it cannot be inherited) and abstract (so it cannot be instantiated) under the covers; furthermore, the compiler checks that everything on the class is effectively static. It doesn't create a private constructor, as you might think, because there's no real point to do that anymore (instantiation is already prevented by defining the class as abstract) and to avoid the small metadata overhead induced by the additional constructor.