In Java, by convention getter and setter for boolean fields will be isField() and setField(). This works perfectly fine with field names that are adjectives like active, visible, closed, etc.

But how do I name a field that has meaning of a verb, like haveChildren? Add “_ing” to the verb (havingChildren), maybe?

To clarify, I don't have control of the method names (getter and setter) as they are auto-generated by the IDE. So what I need is an appropriate field name so that when the IDE generate a getter for it, it make senses. For example, hasChildren is a perfect field name, but when the IDE generate the getter for the field it would be isHasChildren. How do I solve this?

  • 3
    If this is a bool field, parent would work.
    – yannis
    Commented Oct 11, 2013 at 15:18
  • 2
    If you can get away with inverting the meaning, 'childless' would to the trick. Commented Oct 11, 2013 at 15:22
  • 3
    Seems kind of silly to have to jump through hoops regarding the name of a field in order to avoid a grammatical issue caused by the IDE. Regardless, here are some additional suggestions, though I think the ones already given by others are better: isAllowedChildren, isNotEmpty, isContainer, isLeaf, Commented Oct 11, 2013 at 15:59
  • childless seems to be the way to go. Problem with parent is I already have a parent field to hold the reference to the parent object. I think what I need is a general rule to convert the all verbs to adjectives for boolean fields.
    – dnang
    Commented Oct 12, 2013 at 10:12
  • 1
    I agree with @dnhang that you shouldn't let an IDE dictate things like this. Choosing variable and method names is important to make your code readable, which IDE it is written in should be irrelevant.
    – Digitalex
    Commented Dec 18, 2014 at 17:24

4 Answers 4


Short answer:

  • method names aren't supossed to reflect internal implementation but expected behavior.

Long answer:

haveChildren() should be named hasChildren().

Also I don't see hasChildren() as necessarily being the getter for a boolean class member. I guess such a method would find out whether or not a member of type Collection is empty.

Default name an IDE gives to generated getters and setters aren't supossed to be a law set in stone.

Another point: Interfaces have names for yet-to-be-implemented methods.

If method names were supossed to reflect internal implementation, how would someone be able to ever design an interface ? Interfaces don't have an implementation nor they know beforehand what the implementators will do under the hood.

Take for example the Iterator interface in Java.

When you implement Iterator, even when you have a boolean member named next, you are not supossed to rename hasNext() to isNext() or isHavingNext(). That's an implementation detail. In fact, I've implemented Iterator and what I do is have a member of the type of whathever my class has a list of, named next (not a boolean). hasNext() then returns next!=null.

Also, see this:

class patient {
      private boolean hasPulse;
      private boolean isBreathing:
      public boolean isDead(){ return (!hasPulse & !isBreathing);}

Note that isDead() is no normal getter.

Take IDEs' productivity tools for what they are.

  • 1
    isn't this even more naturally to read? isDead() {return (!hasPulse & !isBreathing);}
    – gebbissimo
    Commented Apr 29, 2020 at 8:57
  • 1
    @gebbissimo Indeed it is. Commented Apr 29, 2020 at 9:17

I would suggest renaming the field to parent so that the getter will be isParent and setter will be setParent.

You can also try childPresent for the variable name and isChildPresent and setChildPresent as the getter and setter.

  • 1
    Same idea as Yannis's comment above but the problem is I already have a parent field to hold the reference to the parent object. I think what I need is a general rule to convert the all verbs to adjectives for boolean fields.
    – dnang
    Commented Oct 12, 2013 at 10:09

You could put does before the verb. Such as doesHaveChildren in your example you provided. Or perhaps shouldHaveChildren depending on the context.

  • 1
    The problem is, I don't have control of the method name because the getter and setter are auto-generated by the IDE (e.g. Eclipse).
    – dnang
    Commented Oct 11, 2013 at 15:07
  • 1
    Just rename the method(s)? Add a keybind to rename methods (if you haven't got one already). Commented Oct 11, 2013 at 15:08
  • @dnhang if it's your code, you can call the methods whatever you like, regardless of what the IDE calls them when it auto-generates.
    – Richard
    Commented Oct 11, 2013 at 16:22
  • 1
    @miguel.martin One reason you wouldn't want to do this is Java-beans. The assumption of isSomething is a part of that specification and many assumptions are made around it, for better or worse, going against this with doesSomething can an will break things in not so obvious ways, leading to bugs.
    – user7007
    Commented Dec 11, 2014 at 20:51

The question is perfectly reasonable. Sometimes renaming the auto-generated method is not enough. Example: JSF managed beans are expected to have isXyz() as the getter method of a boolean xyz property.

I agree with BlackPanther who suggests renaming the field to parent and using isParent as the method name. Per the information hiding principle, getter and setter methods' readability is more important than the attribute's.

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