IsEnabled or Enabled?

Question

Throughout Silverlight and WPF, properties that are boolean values are prefixed with Is (almost all), for example:

• IsEnabled
• IsTabStop
• IsHitTestVisible

In all other Microsoft frameworks (winforms, BCL, ASP.NET) Is is not used. What prompted their team to move away from the original naming convention - is it an evolution or a miss-naming that had to stick?

Answer 1

Personally, I always try to prefix boolean values with something that adds a little more meaning (is, has, can, etc.). My usage comes from the following Microsoft guidelines:

Do name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). Optionally, you can also prefix Boolean properties with Is, Can, or Has, but only where it adds value.

MSDN - Names of Type Members

I don't believe this was always the case This wasn't always the case. Those practices date back to .NET 2.0. Before that, things were fair game. Cleaning up those names in newer versions of the Framework, however, would cause all kinds of headaches (hence some of the Framework code uses the convention and some doesn't).

It definitely makes things more readable though. Even using an example from your question. Which would you rather have?

// ambiguous naming, could mean many things
myTab.TabStop

or

// definitely a true/false value
myTab.IsTabStop

Answer 2

The Is prefix can give a hint about the fact that the property only has a get accessor, and, as Thomas and Rachel said, it's a bool. Skip the prefix if you intend to implement both get and set accessors and its type is other than bool.