8

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?

Yves M.
  • 29,855
  • 23
  • 108
  • 144
Chris S
  • 64,770
  • 52
  • 221
  • 239
  • Quite related to https://stackoverflow.com/questions/3874350/naming-conventions-for-java-methods-that-return-booleanno-question-mark and https://softwareengineering.stackexchange.com/questions/348649/naming-of-bool-methods-is-vs-can-vs – Yves M. Dec 03 '20 at 15:42

3 Answers3

15

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
Justin Niessner
  • 242,243
  • 40
  • 408
  • 536
  • 1
    That's interesting that it's a new recommendation, explains most of winforms not having the Is prefix. – Chris S Sep 01 '10 at 14:29
  • 1
    @Chris S - It's hard to get everything right the first time around. This might've been one of the lessons learned from .NET 1/1.1 – Justin Niessner Sep 01 '10 at 14:35
  • For TabStop, "Is" adds clear value: the property's value tells you whether something is a tab stop; the value is not a tab stop itself. For Enabled, the added value is more subtle. "Is" here distinguishes between whether something is enabled and an "enabled", whatever that would be, maybe an enabled copy the object. Another added value is that the object reads more like English: myObject.IsEnabled. – Edward Brey Mar 07 '12 at 17:41
  • @EdwardBrey reading "enabled" as a noun would be a stretch for the English language. So I think dropping the "Is" is appropriate here – fjch1997 Dec 19 '20 at 19:37
  • @fjch1997 You're right. Noun ambiguity probably isn't the reason. In some other design, differentiation could be required. For example, if you had an immutable `Button`, I could see having `IsEnabled` of type bool and `Enabled` (short for `EnabledButton`) of type `Button` that returns an enabled copy. However, since WPF uses mutable objects, that kind of differentiation isn't required. – Edward Brey Dec 20 '20 at 00:24
  • 1
    Adding `Is` in front of boolean properties allows adding an event notifying of a positive change without a name conflict. For example, you can have a property `IsEnabled` and events `Enabled` and `Disabled`. That kind of event naming would be consistent with the existing event `FrameworkElement.Initialized`. So perhaps the rationale was to make it clear at a glance that the member was a property, not an event. Or perhaps it was to not preclude adding such events in the future. Or perhaps something else; I'm just speculating. – Edward Brey Dec 20 '20 at 00:34
4

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

Personally, I find it useful, if consistently used. It immediately tells you that a Property is a Boolean. You might use it or not, the most important thing is to be consistent about it...

Thomas

Thomas Weller
  • 11,631
  • 3
  • 26
  • 34
3

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.

devnull
  • 2,790
  • 22
  • 25
  • 7
    I'll disagree, I know I've set IsEnabled on some objects before. It's probably because it's a boolean value and not something you can set to any value. – Rachel Sep 01 '10 at 14:19
  • 5
    I would tend to agree with that explanation, but many read/write properties in WPF have this prefix... I think it is rather intended to show that the property is a bool – Thomas Levesque Sep 01 '10 at 14:20
  • @Thomas and Rachel - in fact that's what i wanted to say, but i managed to somewhat write something else :) – devnull Sep 01 '10 at 14:23