IsEnabled or Enabled


I actually got a chance to write a little WinFX code today, which was a lot of fun.  But I did run across one issue that has been in the back of my mind for while.  It is the “Is” prefix on Boolean properties.


 


I started out by using the WinForms Timer class (which, BTW doesn’t work in Avalon because it is tied to the message bump).


myTimer.Enabled = true;


 


When I found my bug I moved to using the Avalon UITimer class which worked like a charm except I needed to change to using:


myTimer.IsEnabled = true;


 


What do folks think is the IsXxx prefix worth the break from the WinForms model?

Comments (45)

  1. John Wilson says:

    I like the winforms model myself; it’s less typing and I prefer an <i>implict</i> is.

  2. IsEnabled should not be a propery, it should be a method (IMO).

    Enabled feels like it should be a property.

    Above all, it should be consistant (both with the "past" and the "current")

  3. Len Weaver says:

    I more or less agree with Dominic. ‘IsWhatever’ is appropriate for read-only properties, but assigning a value to such a property looks strange.

  4. David Bossert says:

    How does that saying go, let the left hand not something something the right? I’m sure you know which one I mean. Anyway, I think this is just a case of that. From a design standpoint, though, I think each of the two naming schemes has its place.

    For example, you might have an object with a ValidationEnabled property that you could set to enable or disable validation of… whatever. If the property was read-only (perhaps because validation is enabled or disabled in the object’s constructor), it would probably make sense to name the property IsValidationEnabled.

  5. Kannan Kalyanaraman says:

    It might be applicable in another scenario’s but for the one posted here it looks strange to me. I would prefer the Winforms syntax.

  6. Steve Dunn says:

    How about compiler/intellisense support for read-only properties? The compiler emits implicit constructors if one doesn’t exist, how about implicit IsXxx for read-only booleans if one doesn’t exist. This will aid productivity as library users can simply type ".Is" to get all the read-only properties.

    I think this will greatly compliment the C# 2.0 feature of differently accessible properties between get/set.

  7. Kevin Daly says:

    I vote for consistency.

    By now we’re all used to Enabled all over the place with both Windows Forms and ASP.NET, so springing IsEnabled on an unsuspecting world would just be cruelty to devs.

  8. Adam Kinney says:

    I like the "IsXxx" format. To me its become similiar to "IXxx" for interfaces. I see "Is" and I know its a bool. I may seem as if its already familiar to me because that’s the naming convention we have chosen for bit fields in SQL (and have been working with Longhorn a lot lately).

    So I say keep it, but I also seem outnumbered :p

    (Thanks for the UITimer tip by the way)

  9. Tosh Meston says:

    I prefer "disabled" a la HTML 4.0. Nice. jk.

  10. Steinar Herland says:

    I think IsXx is only appropriate for functions. [Think IsWindowEnabled in the old WinAPI] Boolean properties are exactly that – I would’nt dream of writing myObject.IsEnabled = true. That’s just plain wrong.

  11. Claudio says:

    I agree with Steinar and Dominic. IsXXX should be the name of a method rather than a property, no matter if it is read-only or not.

  12. Lawrence Pina says:

    It depends on what "Is" is……

  13. Derek Lakin says:

    I’m tending to lean towards the majority here in that IsEnabled sounds more like a method and Enabled sounds more like a property.

    In all honesty I don’t mind which way it goes as long as it’s consistent.

  14. Corrado Cavalli says:

    I like the WinForms syntax, while IsEnabled is appropriate for read-only properties.

  15. Steven says:

    Why is "IsEnabled" appropriate for Read-Only properties? Why not call them "Enabled" too? .NET Reflector is using the icon to differentiate between read-only, read-write and write-only properties which is enough for me (VS intellisense should do the same).

  16. I vote for Enabled, since the implicit "Is" is clear without being written explicitly.

  17. .. says:

    Whatever turns your crank works.

    I dont have set rules for doing things, we do what fits best in that scenario. We do a case by case judgement call in our code. Hard and fast rules have theyre place but not everywhere.

    Whatever feels good for that part of the code. Usually the simplist solution works best even though it appears like its not.

    As for having Is only on methods I dont think thats a good hard and fast rule to use, if (something.IsEnabled) reads naturally unlike something like ( if (something.Enabled == true)

    Think natural.

  18. .. says:

    the Is prefix usually doesnt read well if its being Explicitly tested.

    this reads well naturally

    if (something.IsEnabled)

    {

    ..

    }

    this does NOT read well naturally

    if (something.IsEnabled == true)

    {

    ..

    }

    if (something.Enabled == true)

    {

    ..

    }

    CODE NATURALLY, people dont do that, they code like a machine, but the language is our interface with the machine. its not maintained by machines its maintaned by people.

  19. .. says:

    Kinda offtopic but to do with readability/maintainability of c++ code.

    Usually the access modifiers are specifed once or until they needt o be change.. ie..

    public:

    ctor()

    someMethod()

    private:

    somePrivateMethod()



    This is very dependant on tabbing (or spaces I hate tabstops as every app does them diff).

    I nowdays use…

    public __gc class SomeWrapper

    {

    public: SomeWrapper()

    {

    sc = new SomeClass();

    }

    public: double someMethod(double num1, double num2)

    {

    return sc->Add(num1,num2);

    }

    public: ~SomeWrapper()

    {

    delete sc;

    }

    private: SomeClass* sc;

    };

    — The above is a simple wrapper class for C++/CLI to C++. But it demonstrates the use of the access modifiers on EVERY member.

    To me this clearly shows access to every member, while I know C++ legacy coders (ie., old style developers who love KnR code which I also hate).

    Anybody else do the same?

  20. Iain says:

    I’m with the previous commenter here. if (thing.IsEnabled) reads better then if (thing.IsEnabled).

    On the other hand, thing.Enabled = true; reads better than thing.IsEnabled = true;

    An Is prefix is a bit of a throwback to hungarian notation – if it’s a boolean, prefix it with Is. On that level it’s pretty silly. I don’t think it confers any advantages except in the if case, and it loses because of both the assignment case and the hungarianness.

  21. Max says:

    I prefer the "Is" prefix for Read-Only properties. The "is" underlines the fact that something _is_ as it is and can’t be changed directly.

  22. +1 for taking the Is prefix off settable properties.

  23. if we see the "Is" as a reminder for the boolean type, then it would be logical to always use some prefix for each type ?

    i know developpers who prefer to prefix every variable with str_, i_, etc, and even the functions with f_

    * But i think with intellisense and such technologies, the type of a property appears immediately and so "Enabled" is sufficient and more logical (in comparison to other types) than "IsEnabled".

    * i agree also that sometimes the "Is" is more meaningful, for example

    CheckBox.IsLiteralContent makes you think to something very different than

    CheckBox.LiteralContent

  24. .. says:

    I am not a fan of HN (Hungarian Notation) as I think it polutes and spams the codebase. "Is" on the other hand is not HN, its a description or the content, "is it something", it is only useful if you are not explicitly testing something, it loses all meaning and becomes polution if you use it explicit tests for ==.

  25. Tom McKearney says:

    "Is" is NOT the only boolean prefix. Unfortunately, people treat it as such. I recently saw code that had a boolean called "IsPromptUser". This was supposed to tell if you should prompt the user for something. This did NOT read like English.

    Similarly, if you have a boolean that determines whether or not a tree node has children, you’re not going to call it "IsHasChildren". So, please don’t make up some arbitrary rule about "Is" being "the way to do things" for any scenario. If you want things to read like English, you should also attempt to follow English grammar too.

    "PromptUser" and "HasChildren" are very valid boolean names. Any modifications to them would only server to obfuscate the meanings.

  26. .. says:

    If the shoe fits wear it. Do what works best for you instead of this "You stuck your head in the oven so I will too" attitude.

  27. Wes says:

    I think "Is" should only be used when it is talking about something (ie next to a noun). Like IsControlEnabled, or IsLiteralContent. But if you don’t know what "It" it is talking about then don’t use it like in the case IsEnabled. What is enabled? It is not completely clear what the "Is" is when you read that.

  28. Jeffrey Sax says:

    I like Tom’s comment about other prefixes. How about putting it this way:

    A boolean property always gives the answer to a yes-no question:

    Is ‘it’ Enabled?

    Does ‘it’ Have Children?

    Should ‘it’ Prompt the User?

    Has ‘it’ Timed Out?

    Does ‘it’ Work?

    ‘It’ always refers to the object whose property we’re getting or setting.

    In my view, the property should be named by what comes after the ‘it’ in the question. If there’s a verb after the ‘it’, that verb should be included in the property name.

    For methods, a verb should always be included to reinforce the idea that some work is involved in determining the return value.

  29. Munish Gupta says:

    +1 for Enabled. Its the same even in VB6!

  30. Brad Abrams says:

    BTW — Nikhil Kothari (http://www.nikhilk.net/) asked me what the guidelines acutally say about this topic. Clearly they can be improved, but for your reference here is the text:

    Do name Boolean proprieties as following:

    Use an affirmative phrase (CanSeek instead of CantSeek).

    Optionally prefix with Is, Can, Has but only where is adds value. For example CanRead is more understandable than Readable however Created is actually more readable than IsCreated. Having the prefix is often too verbose and unnecessary particularly in the face of intellisense in the code editors. It is just as clear to type “MyObject.Enabled =” and have an intellisense drop down pop up true and false as it is to have “MyObject.IsEnabled =”, yet the second one is more verbose.

  31. Keith Hill says:

    +1 for Enabled. I agree with the other folks that "Foo.IsEnabled = true" doesn’t look right.

  32. Sean Terry says:

    Enabled.

    I only use Is for methods, and then only when an Is isn’t implicit. Most all prefixes just make for more keystrokes.

  33. Frank Hileman says:

    Enabled. "Is" just makes it that much harder to find the property in the enormous list provided by intellisense.

  34. Om says:

    Hi

    I prefer Enabled.

    The only pb i encounter lives on homophon name but with diff type clash

    I had a pb with synchronisation wa eg i had to reveal both a tracking enable and a last resync date. my choices (after some mix and remix) go for

    bool Synchronized;

    string SynchronizedDate;

    on need i also use tech like XxxText etc ..

    think about the Created (implicit bool), CreatedDate (explicit date counterpart)

    my 0.2[]

  35. Om says:

    … eg prefer suffix to prefer …

  36. .. says:

    Would this contestant like to try again except this time in English.

    "I prefer Enabled.

    The only pb i encounter lives on homophon name but with diff type clash

    I had a pb with synchronisation wa eg i had to reveal both a tracking enable and a last resync date. my choices (after some mix and remix) go for

    bool Synchronized;

    string SynchronizedDate;

    on need i also use tech like XxxText etc ..

    think about the Created (implicit bool), CreatedDate (explicit date counterpart)

    my 0.2[]

    "

  37. Marco Russo says:

    IsXxxx is for function.

    Enabled as a property is good.

    Anyway, let’s define a convention and follow it consistently across the Framework. Having different conventions for different namespace/libraries would be the very worst thing to do.

  38. google9999 says:

    For all bool type i prefer to have IsEnabled and for all properties i prefer Enabled.

    Based on the usage i will go and define the term.

  39. Ken Brubaker says:

    My personal rule is that Boolean fields/properties should be assertions. From a grammatical perspective Enabled could mean IsEnabled or WasEnabled, which is ambiguous. It gives my code a bit more verbose style such as ShouldBlock, HasResources, IsReady, WasFound. However, the intention is crystal clear.

    In the end, however, the CLR already has a considerable code base. I would pick the most commonly used paradigm in the CLR and go with it. But, please specify. I see no reason to leave the topic to the vagaries of an individual CLR team or 3rd party developer.

  40. Tom McKearney says:

    Why would you keep track of the fact that something _used_to_be_ enabled? That doesn’t make any sense.

    And WasFound is too unclear. What was found? I’m assuming that you would be talking about a variable in code. If that’s the case, wouldn’t "foundItem" be a more descriptive variable name than "WasFound" (assuming that you were looking for an "item")? I velieve that "IsReady" is no more clear than "Ready". Of course, I never do this:

    if (obj.Ready) {}

    or

    if (!obj.Ready) {}

    I believe that it is very hard to read and hard to tell the difference between these two when scanning code.

    So, I always explicitly compare like:

    if (obj.Ready == true) {}

    and

    if (obj.Ready == false) {}

    Given this much clearer way of doing things, having "Is" in front of the variable gives no additional information. Since it’s being compared to a boolean, it’s obvious that it’s a boolean. Thus, no need for Hungarian-ish prefixing.

    This logic actually applies to the more cryptic style above too. Since the variable is being used as a boolean, it must be a boolean and thus, no "Is" needed.

    My $0.02

    T

  41. Abubakar says:

    Thumbs down to "Is" thing. Enabled is just fine.

  42. Henry Stapp says:

    I seem to remember reading somewhere (was it in Code Complete?) a suggestion to name booleans as yes/no questions i.e.

    IsEnabled

    HasData

    CanUpdate

    I like this because it provides a hint to the reader that makes the code more readable. I’d agree that it makes sense for read-only properties, though.

    JM$0.02

  43. I may be a bit late to the party here, but i thought i might drop my $.02…

    I rarely like Is notation because it is, IMHO, less readable for negative tests… i.e,

    if (myTimer.IsEnabled==false)

    reads,

    "if my timer is enabled is false"… too many is’s. weird.

  44. Brad Abrams says:
  45. I like the "IsXxx" syntax for field (column) names and internal variables (isXxx), but not for properties. Personally, it would be like naming a property "strTitle."