use areFoo or isFoo?

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

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>.

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.

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

vs.

object has valid setup parameters

I think you see what I’m hinting at.

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.

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.

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.

Filed under: softwareengineering - @ 07:57

Thẻ: methods, return-type

Thiết kế website giá rẻ

Danh mục

use areFoo or isFoo?