Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I think everyone will agree that the following boolean variable/property names are standard:

  • UserIsAdmin
  • OrdersAreClosed

The important thing to note about boolean expressions is that they are stated and then evaluated as true or false. User is admin. False. You get the point.

However, lately I have seen an increase in booleans being formed this way:

  • IsUserAdmin
  • AreOrdersClosed

Am I the only one who doesn't think this sounds absolutely ridiculous? You're not asking "Is user admin?" and then waiting for a yes or no. You're making a statement of "User is admin" and waiting for a true or false evaluation.

Microsoft has been doing this a lot lately, as well as the programming behind our Telerik web controls. The thing is that I don't understand where this is coming from. It never used to be popular, leaving me to wonder if it's just me who is noticing this or if this is a trend that is actually on the rise and, if so, what's the point?

share|improve this question

closed as not constructive by Jarrod Roberson, Mark Trapp Aug 22 '11 at 1:53

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

14  
"I think everyone will agree that the following boolean variable/property names are standard" Well, there's your first incorrect assumption. I always use the 2nd way. (Actually, I don't include the noun, as I would expect an IsAdmin property on a User object, thus the "User" is redundant...) –  Joe Aug 22 '11 at 1:16
1  
IsAdmin is a version I would use. It's when people use "IsUserAdmin" that drives me nuts. I look at the code and want to ask it, "Are you asking me a question?" But, in our app, we have a static utility file and UserIsAdmin() is a method that checks the roles, so it fits there. Otherwise, I agree with your redundancy statement. –  oscilatingcretin Aug 22 '11 at 1:22
1  
What if I am asking "Is the user an admin?" and then checking to see if the user belongs to an admin group and setting the boolean value as an answer to this question? –  JeffO Aug 22 '11 at 1:40
1  
@Jarrod I'm not sure that warrants a close. There are tons of questions here that start off with false assumptions and are answered by corrections of those assumptions. –  Rei Miyasaka Aug 22 '11 at 1:58
2  
@oscilatingcretin - I agree with you. That way, the code works out most similar to English grammar: "If the user is an admin..", "if (user.IsAdmin)" –  Carson63000 Aug 22 '11 at 2:18
show 3 more comments

3 Answers

As @Joe said in his comment, it's redundent to put the name of the object into the method name. Say you call:

if (user.isUserAdmin()) {

That's rather silly, because the method name repeats the class name (probably something like User, or maybe a subclass called Admin). Beginning with is or are or can makes sense in the immediate context of the object you're calling it on.

However, it makes less since when you're getting information from an object about another object it's responsible for. For example:

if (user.ordersAreValid()) {

Then it will get a little fuzzy. areOrdersValid makes sense because it's in the form of a question. But on the other hand, ordersAreValid becomes a sentence when combined with a control structure like if or while (e.g. "if orders are valid"). I lean toward the latter, but it's might be more a matter of taste.

share|improve this answer
add comment

One of the reasons to do that is to help with auto-completion. For example, Windows Forms apps suffered from an inconsistent .NET Framework APIs where you would never know if you must include "is" or not. For example, to check if a checkbox is checked, you would have to write this.checkbox.Checked. In WPF, this was changed, and now you have to use this.checkbox.IsChecked which is easier to remember.

This being said, I don't see how AreOrdersClosed would be better than OrdersAreClosed. A possible explanation would be the same auto-completion: it's easier to find boolean properties and fields.

But this can be criticized:

  • If we start doing that, why not also using Hungarian notation? Since Hungarian notation must not be used in most languages used today, there is no reason to use it just for booleans.
  • Boolean variables can start by is, are or can. Three prefixes for the same type is too much if the only reason is a better auto-completion. If we want to be consistent, AreOrdersClosed must be IsOrdersClosed and CanResumeDownloads must be IsResumeDownloadsPossible, which is ugly.

Probably people start with the properties grammatically formed as Is+<Adjective>, and when it comes to the rare cases of <Noun>+Is+<Adjective>, they just put it as Is+<Noun>+<Adjective> to have a more uniform API.

Now, there are a few cases where "is" can be found between two words in a name of a variable, and I can't remember any valid case from .NET Framework. Actually, looking at your examples, I feel like there is a refactoring to do:

  • IsUserAdmin can be IsAdmin, as suggested by the comments,
  • AreOrdersClosed may also be renamed into AreClosed or something else depending on the context. For example if this is a value which indicates whether somebody cannot add new products to the cart, I would rather create a property IsClosed or IsFinished to the Cart or the Order.
share|improve this answer
1  
I agree with IsChecked. I would not, however, agree with IsCheckBoxChecked. I also agree with your criticisms. If you're going to do it with booleans, why not give the same attention to longs, strings, etc. In fact, why just go all hungarian with booleans, using boolCheckBoxChecked? Regardless, to base your variable naming convention around the features of your IDE just sounds like poor practice. –  oscilatingcretin Aug 22 '11 at 1:34
2  
Nobody will agree with CheckBox.IsCheckBoxChecked. –  MainMa Aug 22 '11 at 1:39
    
It's how you make it sound more pleasing / correct. –  Joset Aug 22 '11 at 1:41
    
If using a naming convention makes your IDE more efficient for you, I'm all for it. –  JeffO Aug 22 '11 at 1:42
add comment

It's just a way of narrowing down a search in auto complete/Intellisense. When you start writing a conditional, typing in "Is" is a good way to find what you're looking for without having to scroll through everything, when you don't know the name of the member you're looking for.

The only reason we do this for "Is" and nothing else is because we know that boolean members are often going to be used in the context of a branch or loop. It's no coincidence that booleans are among the few types that most languages have so many special keywords and structures to recognize.

I'm sure we'd find more things to notate with similar prefixes if we could figure out what the appropriate contexts would be.

share|improve this answer
    
Just for fun... Notating all things, not just bools, with prefixes was popular for a while in Windows programming. Stuff like lpszCityName for a string containing a city name (lpsz = long pointer to string terminated with zero (\0)) en.wikipedia.org/wiki/Hungarian_notation –  Domingo Ignacio Galdos Feb 28 at 21:17
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.