Java boolean getters "is" vs "are"

I know that the convention in Java for boolean getters is include the prefix "is".

isEnabled
isStoreOpen

But what if the subject is plural? That is, what if instead of wanting to know if a store is open, I wanted to know if all the stores are open?

isStoresOpen() doesn't make sense in English.

I'm tempted to write getters like:

areStoresOpen
areDogsCute
areCatsFuzzy

And I think that would make sense, but I've been told by others that I should just suck it up and abandon subject verb agreement and use isStoresOpen, isDogsCute, isCatsFuzzy.

Anyway, what should I do for boolean getters which operate on a plural subject?

How about having decent enough english and following Java standard:

isEveryStoreOpen() or isEachCatCute()

When in doubt of the right word I always like to hit up the thesaurus.

I can't remember which book this was from, but the essence is that code will be read many more times than it's written. Write for readability.

The convention is to prefix the getter-method with "is" not the variale itself.

e.g.

private boolean enabled;

public boolean isEnabled() {
    return enabled;
}

and

private boolean storesOpen;

public boolean isStoresOpen() {
    return storesOpen;
}

---

>isStoresOpen() doesn't make sense in English.

It might not make sense grammatically, but it follows the convention and looks readable enough.

The Java Bean specification says to use get for getters unless it's a boolean then use is. are is non-standard and will not be recognized by anything that expects standard Bean naming.

Lots of tools expect is or get and won't likely recognize are.

Try rephrasing them, like getDogsAreFuzzy() or getStoresAreOpen() or things like that for better compatibility and conventions.

What do you code, English or Java?

When I read Java code, I expect things to be structural. Boolean methods starting with is is a good structure.

return 0; 

- isEnabled() can also be written as getEnabled() in Java naming conventions.

- Its just a good habit to follow the naming conventions, help when you are working with Java Beans.

In general I think code should be as easily readable as possible so that a method can almost be read as a paragraph (as espoused by Clean Code). Therefore, I would name the method to sound / read as easily as possible and go with the grammer rule of are. With modern IDEs it is easy to find methods without looking specifically for get / is.

However, Kumar makes a good point about beans. A lot of tools will only look for get / is. In that case I might consider having both methods. One for ease of reading and one for tool use.

In your question you're explicitly asking about getters. A getter returns some information about one instance of your class. For example you have a class Store. Now, isStoreOpen is a perfectly fine method name for a getter.

Next, you mention a method that checks if all stores are open. This method isn't a getter at all, because it doesn't return information about one instance but for all. Of course unless there is a class Stores. If this is the case, you should rethink your design, because Java already has ways to store a number of instances, e.g. arrays or collections, so you don't have to write extra classes.

If this is not the case, then this method name is perfectly fine. An alternative may be just allStoresOpen without the 'is'.

TL;DR: If you're dealing with multiple instances, it's not a getter. If it is, your design is bad.

Quite honestly I would say definitely forget about the are* and stick with is*. Think of the "is" as the variable meaning and make a better name if possible.

I would say is isStoresOpen doesn't sound that bad, but you can make isStoresAreOpen if that sounds better for you.

But my general idea would be to stick to the conventions. Which is using "get" for getters and "is" for boolean types. Personally I think using "is" is sometimes already problematic. Yes - it does look good in "if" conditions, but sometimes I just write "get" when coding and check the drop down list for my needed variable and start wondering what's wrong and why I can't find it, then I realize it starts with "is"...

In object-oriented programming, this should rarely, if ever, occur since Store or Cat or what have you should be a separate class, with its own isOpen() or isFuzzy() method. If you have a higher type, consider splitting down to the more atomic level that you're actually using. In general, objects should not be plural at the lowest level.

isStoresOpen() in this StoresOpen is seems like a plural,

When you follow that Java Naming Convention and Java Beans Standards, they have predefined prefix's for boolean and other type, so you should follow Java Beans Naming Convention.

Let's come to your point When you see storesOpen as in an English prospective, yes it looks like plural. Once again take deep observation into that word,

Here

storesOpen is plural according to English grammar,

The out come of the isStoresOpen is not plural, instead of it is singular or you can say it is scalar in terms of programming convention.

It's out come is boolean, just true or false

Not like your English plural statement true's or false's

Not an array of true or false, or not a collections of true or false

So, here we can say that, here we are concerned with value that is return from that boolean bean method, not the name given to the property of class to point real world entity.

One more important thing is, whenever such boolean properties are used in classes and those are used by predefined libraries in any framework, then framework with use prefix 'is' for retrieving boolean values,

why means it's not that much of smarter than you as you know English grammar like plural/singular, multiplexer etc...