128

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?

Mariusz Jamro
  • 30,615
  • 24
  • 120
  • 162
kodai
  • 3,080
  • 5
  • 32
  • 34
  • 4
    I never see before a `are*()` getter. – rekire Oct 18 '12 at 17:44
  • Nice question, but I don't think it belongs here. – Naftali Oct 18 '12 at 17:44
  • 23
    I always write `are*()` getters if they're grammatically correct. – Roddy of the Frozen Peas Oct 18 '12 at 17:44
  • 2
    If your object is a bean, I think you have to stick to either `is` or `has`... – assylias Oct 18 '12 at 17:45
  • 4
    if you are using are*() getter then it should return boolean[] in most cases, i think. – Juvanis Oct 18 '12 at 17:47
  • 2
    Very good question. Wondered this myself, quite a bit. As a lot of the answers have already pointed out, most frameworks, IDEs, and anything relying on a convention that I've encountered use the "get" / "set" / "is" pattern. Even if this is not a concern in your application, I would follow that convention regardless - your code will be far easier to follow (even by you) if you maintain a consistent naming convention (even if it doesn't sound grammatically odd at times). – Paul Richter Oct 18 '12 at 17:53
  • It's true and I think in the end your right. It just seems wrong that I'm writing my code for the IDE's. Their goal is to make things easier for me but I end up having to bend my code to fit their expectations. – kodai Oct 18 '12 at 18:00
  • Honestly even isStoreOpen returning true/false doesn't sound right. If you say isStoreOpen then it's a question and you'd want to say yes or no, whereas you'd say true or false to a statement, which should look more like "storeIsOpen"... not that I advocate using that, it's definitely awkward – DHall Oct 18 '12 at 19:17
  • For me common sense wins with the convention. Just be consistent. – Mariusz Jamro Mar 31 '13 at 19:34
  • 1
    'hasOpenStores()'? Only logical if you compose your objects. I've never needed 'areX()' to be gramatically correct. – atamanroman Mar 31 '13 at 19:40
  • 9
    Often it is not too hard to rephrase things so that a plural "all" becomes a singular "any" with a negated result (e.g. De Morgan's laws). `areAllStoresClosed()` --> `isAnyStoreOpen()` or `areAllStoresOpen()` --> `isAnyStoreClosed()` – jacobq Jan 22 '14 at 16:10

12 Answers12

148

How about having decent enough english and following Java standard:

  • **are**StoresOpen() > to be >> isEveryStoreOpen()
  • **are**CatsCute() > to be >> isEachCatCute()

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

Ahmed Nabil
  • 17,392
  • 11
  • 61
  • 88
satur9nine
  • 13,927
  • 5
  • 80
  • 123
  • 31
    +1, this clearly conveys whether the returned value means isEveryStoreOpen() or isAnyStoreOpen() unlike the ambiguous isStoresOpen(). – Imre Jun 24 '15 at 09:49
  • 12
    +1 This should be the accepted answer! Makes sense grammatically while keeping the Java `boolean`s `is` prefix convention. Plus, it provides a little bit of extra info that will be *really* useful for those non-native English speakers that happen to be maintainers of the codebase. – higuaro Oct 07 '18 at 04:56
  • 4
    This answer changed my life! And it should be the accepted answer. – Marcel Blanck Jan 10 '19 at 13:16
  • 1
    Yeah, but how do you phrase a variable name that conveys the following: "Are SOME [not all] stores open"? – Michael P. Nov 29 '20 at 00:23
  • 1
    How about `isAnyCatCute()` or `isAtLeastOneCatCute()`? – satur9nine Nov 29 '20 at 04:57
  • 1
    Thanks. How'd you phrase a sentiment to the effect of "isAtleastTwoCats," only with proper grammar? – Michael P. Dec 18 '20 at 17:20
  • @MichaelP. If this is something you are requiring in your codebase, then I would say you need to relook at the design of your classes. Your methods may well be expected to tell that there are no stores open, all stores open, is any store open, but if your require is strange enough that it warrants a relook at the design. You can write a method `getCountOfOpenStores()` and use the number in the logic directly. As a class exposing methods to others, this would be my choice rather than a method that checks if 2 stores are open. PS: This is all only from a practical implementation viewpoint. – cyphx Jun 07 '21 at 15:30
67

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.

John
  • 15,990
  • 10
  • 70
  • 110
  • 25
    Clean Code - Robert Martin – John B Oct 18 '12 at 17:50
  • John B: I haven't read that book; maybe I read a reference to it. Another book for my list, though. :) – John Oct 18 '12 at 17:55
  • 9
    But be very careful you don't go too far. `storesAreOpen()` would likely be the most grammatical (because of `if(storesAreOpen())`), but the boolean part of the name is now hidden in the middle of the method name, which breaks Java conventions _and_ readable code. – Izkata Oct 18 '12 at 21:04
  • @nalply It means being able to understand the intent of the code after being away from it for six months. It means not making it difficult for someone else to understand the code. (Note: I wasn't necessarily taking a stand on `is` or `are` here.) – John Oct 18 '12 at 21:58
  • 3
    He answers the question in a very general way. It's true he doesn't address the specifics, but this is an answer. It may seem trite, but there is value to it (at least 24 people think so). – George Stocker May 16 '13 at 01:17
  • 5
    in order to clarify the answer I would add remark that **areStoresOpen()** is a good choice here. – kiedysktos Apr 14 '16 at 08:48
38

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.

Bhesh Gurung
  • 50,430
  • 22
  • 93
  • 142
  • Your answer makes sense, and I appreciate it. I think from an authoritative right/wrong position, you're right. I just don't want a convention that was intended to help us by being obvious, clear and easy to understand to abandon that purpose for the sake of adhering to its rules. But you're right - this is how it is, and that's what I asked about. – kodai Oct 18 '12 at 18:21
  • @kodai: I think it should not be considered as rule, but just a convention. But I believe while, writing code not following the convention, if it is not required, to make the code readable is the way to go. – Bhesh Gurung Oct 18 '12 at 23:47
19

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.

Steve Kuo
  • 61,876
  • 75
  • 195
  • 257
18

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.

Kevin Rubin
  • 587
  • 8
  • 17
7

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;
Ilya Gazman
  • 31,250
  • 24
  • 137
  • 216
5

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

Kumar Vivek Mitra
  • 33,294
  • 6
  • 48
  • 75
3

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.

John B
  • 32,493
  • 6
  • 77
  • 98
3

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.

Kirill Rakhman
  • 42,195
  • 18
  • 124
  • 148
2

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

Arturas M
  • 4,120
  • 18
  • 50
  • 80
2

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

Anil Kumar
  • 21
  • 2
1

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.

asteri
  • 11,402
  • 13
  • 60
  • 84