IsEnabled or Enabled?

Question

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

Isenabled
IsTabStop
IsHitTestVisible

In all other Microsoft environments (winforms, BCL, ASP.NET) Is is not used. What prompted their team to move away from the original naming convention - is it evolution or oversight that they had to adhere to?

Answer 1

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

Indicate the name Boolean properties with an affirmative phrase (CanSeek instead of CantSeek). Optionally, you can also prefix Boolean properties with Is, Maybe, or it has, but only where it adds a value.

MSDN - type member names

I do not think this has always been the case. It is not always so. These methods are for .NET 2.0. Before that, everything was honest. However, clearing these names in new versions of the Framework will lead to all kinds of headaches (therefore, some of the Framework code use the convention, and some do not).

It definitely makes things more readable, though. Even using the example from your question. Which would you prefer?

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

or

 // definitely a true/false value myTab.IsTabStop 

Answer 2

The Is prefix can give us a hint that the property has only a get accessory, and, as Thomas and Rachel said, this is a bool. Skip the prefix if you intend to implement both the get and the tester, and its type is different from bool.

Answer 3

The Is prefix is ​​part of the official Microsoft Framework development guides (this does not mean that all MS products adhere to it ...).

Personally, I find it useful if it is constantly used. It immediately tells you that the property is a Boolean. You can use it or not, the most important thing is to be consistent in this regard ...

Thomas