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 have never seen the use of "are" for boolean methods, but the use of "is" is very common.

When I want to use "are" is usually because I am passing multiple variables, or a list of objects.

I suppose I could rationalize my list of objects or multiple variables as one thing, such as "isSetupParametersValid", but that would still be plural.

Is the lack of use of "are" in boolean methods, simply an arbitrary convention or a side-effect of using best practices. If it's a side-effect of best-practices, which ones?

Note: for non-native English speakers "is" refers to a singular object, "are" refers to plural/multiple objects

share|improve this question
Well, each object is usually a single object, so myCar.areFast() isn't really appropriate. If your object is a collection and the are* method actually applies to every member, then I could see this happening, but then you might be running close to the line of violating the single-responsibility-principle and might be integrating multiple classes too tightly. –  Joachim Sauer Sep 30 '13 at 14:21
@JoachimSauer Sometimes it isn't practical in JSF to test conditions of many individual objects when you could create a collection interface instead. –  Neil Sep 30 '13 at 15:00
isSetupParametersValid may be not OK, but instead of messing with plural / singular, I'd rather rename it to isSetupParametersCollectionValid - which would be both syntactically and semantically all-right, along with keeping uniform usage of "is-" prefix –  gnat Oct 1 '13 at 12:10
@gnat I'd go with isValidSetupParameters (or hasValidSetupParameters, as an afterthought) –  Izkata Oct 3 '13 at 18:36
@Izkata I believe yours isValidOfManyWaysToSkinACat –  gnat Oct 3 '13 at 18:41

6 Answers 6

If you are talking about Java, you could run into problems because JavaBeans are defined with is<PropertyName> (see Spec Chapter 8.3.2)

I think, some frameworks are very rigid and use is<name> for setting booleans by reflection, so they won't find are<name>.

share|improve this answer
It has happened to me on occasion to want to use "are" and then be forced to use "is" instead due to java beans naming protocol. –  Neil Sep 30 '13 at 15:01
@Neil: in those cases using "get" might look better (and be just as valid) –  Joachim Sauer Sep 30 '13 at 18:44
"is" prefix is only for primitive boolean properties. With object Boolean the "get" prefix is still used –  Kemoda Oct 1 '13 at 8:22
@JoachimSauer getAllDirty doesn't sound as good as areAllDirty, but I suppose it depends on the circumstances. In general, you'd be right. –  Neil Oct 1 '13 at 8:50

You should use "is" or "are" as appropriate for the number of objects in question. You're still maintaining "good form" of asking a question with the boolean variable. ie. "is it ... ?" or "are they ... ?"

So I don't see anything wrong with using "are" with a plural object.

In cases where the answer isn't immediate, then the primary questions your should ask yourself are:

  • Does it make the code more readable and expressive regarding intent?
  • Is it likely that a future change will invalidate how you phrase the boolean question?
  • Does the answer invalidate the boolean nature of the question?

That third question is a bit odd, so let me give a concrete example. IsPointValid? is answered pretty clearly with "yes, it is" or "no, it is not." When asking ArePointsValid? we potentially have a third case of "partially valid: some are, some aren't." If you have that third case, then use a different variable type than a boolean.

Also keep in mind that the boolean question is an aid to the expressiveness of the code. It's not an attempt to create grammatical correctness within the code. So long as you don't get too hung up on is vs. are then your code will be fine and others will understand the intent.

share|improve this answer
Good point; reason to use IsAny and IsEvery... –  Thijs van Dien Oct 3 '13 at 16:22

You often find has as an alternative to to is. In your case you could opt for hasValidSetupParameters accordingly, which makes perfectly sense. It is not part of the JavaBeans specification mentioned earlier, though.

I would speak against using areSetupParametersValid, for the following reason: Our main goal with naming methods should be to make code readable. I.e., in an ideal world code would read like sentences. Coming back to your example this means that your options are

object are setup parameters valid


object has valid setup parameters

I think you see what I'm hinting at.

share|improve this answer

The trouble with 'are' as a prefix is what does it apply to? 'is X in state Y' is perfectly clear to all, but 'are Xs in state Y' is not so clear - does it mean are all X objects in that state, or only some of them? What if only some of them are not in the correct state or all of them - do you need a response that says "yes/no/partially"?

In cases where you think the English grammar suggests using are as a prefix - eg "are setup parameters valid", you can easily rephrase the question to be 'is the setup configuration valid', making a query on several items into a yes/no response to a single collection.

Its pretty trivial though, and the considered standard is to use 'is', so I'd say just keep using is and not worry about it all.

share|improve this answer

Is the lack of use of "are" in boolean methods, simply an arbitrary convention or a side-effect of using best practices.

The answer depends in part on the language and framework that you're using.

For example, in Objective-C you should always use foo or isFoo and never areFoo because the first two are compatible with Key-Value Coding while the last is not.

In object oriented contexts, methods like isFoo are common while methods like areFoo are not because the thing to which the test applies is usually the object receiving the message. Since you can usually call a method on only one object at a time, the plural verb are doesn't make sense.

In your question, you seem to want to ask the object whether some set of values that you're passing in are valid instead of asking about the object itself. It might be more conventional, and therefore easier for others to understand, if you turn that question into a question about the receiver. Instead of myObject.areParemetersValid(...), consider myObject.isAbleToUseParameters(...) or more simply myObject.canUseParameters(...).

To summarize, the convention isn't arbitrary -- it results from the fact that most OO languages let you call a method on only one object at a time.

share|improve this answer

Your question makes a limiting assumption. Let's take a step back here. Why not just bool ParametersValid (or Boolean parametersValid)? It's perfectly sufficient in my opinion.

All those isThis, isThat remind me of that anecdotal secretary who files everything under "T" ("the rent", "the invoices" etc.) :)

If the need for such prefixes becomes acute (it's not immediately obvious what parametersValid stands for), it may indicate the object design is simply bad.

Using prefixes is Hungarian notation of sorts and in this context, it's poor man's substitute of proper refactoring and splitting the class.

Regarding Caleb's criticism:

OP's question is about the particular isFoo style of naming boolean methods which is conventional in a number of languages

Maybe, but the question is not tagged with the name of any particular programming language, so I treat it as language-agnostic.

suggesting a different convention is not useful.

I'm not really suggesting a different convention, I'm rather saying that one does not need to follow any strict convention in this aspect, other than common sense and clear naming in general.

The idea that some strict convention is required is what created the OP's problem in first place.

If he adopts my point of view, his problem goes away, hence my answer is (potentially, of course - like any other answer) useful.

I opt for simplicity. See BackgroundWorker class in .NET. It has a CancellationPending property - not IsCancellationPending, not WasCancelledor HasBeenCancelled etc. Just keep it simple!

Furthermore, the convention you suggest is ambiguous by your own admission ("...it's not immediately obvious...")

I wrote it conditionally, you took it out of context. If it's not immediately obvious ... implies the class is too big, which is a problem in its own right.

Finally, the is in isFoo should be read as a verb; this use of prefixes is distinct from any Hungarian notation and in any case it's not necessarily indicative of poor design.

Verb or not verb, it's only reflecting the fact that the return type is boolean, which is redundant.

That's why I said it's Hungarian notation of sorts.

share|improve this answer
Care to comment, downvoter? Giving the reasons of why you disagree with my point of view is more insightful than simply clicking -1. –  Konrad Morawski Oct 1 '13 at 10:07
OP's question is about the particular isFoo style of naming boolean methods which is conventional in a number of languages; suggesting a different convention is not useful. Furthermore, the convention you suggest is ambiguous by your own admission ("...it's not immediately obvious..."). Finally, the is in isFoo should be read as a verb; this use of prefixes is distinct from any Hungarian notation and in any case it's not necessarily indicative of poor design. –  William Shakespeare Oct 1 '13 at 10:32
IMO the most useful aspect of is prefixes is not that it indicates a specific return type (although that's implied by the nature of is), but rather that it reads more naturally. if (bar.isFoo()) {...} is somewhat easier to grok than if (bar.foo()) {...}. In this regard, the convention is essentially the opposite of Hungarian notation which is notorious for making code harder for normal people to read. –  William Shakespeare Oct 1 '13 at 10:57
@Caleb that's a matter of taste. There is no absolute truth when it comes to conventions, naming practices etc. I gave my opinion to broaden the spectrum of views. –  Konrad Morawski Oct 1 '13 at 11:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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