10

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 Oct 11 '13 at 15:18
  • 2
    If you can get away with inverting the meaning, 'childless' would to the trick. – Kilian Foth Oct 11 '13 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, – Dr. Wily's Apprentice Oct 11 '13 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 Oct 12 '13 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 Dec 18 '14 at 17:24
7

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 pulse;
      private boolean breaths:
      public boolean isDead(){ return (!pulse & !breaths);}
}

Note that isDead() is no normal getter.

Take IDEs' productivity tools for what they are.

2

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 Oct 12 '13 at 10:09
0

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 Oct 11 '13 at 15:07
  • 1
    Just rename the method(s)? Add a keybind to rename methods (if you haven't got one already). – miguel.martin Oct 11 '13 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 Oct 11 '13 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. – Glenn Nelson Dec 11 '14 at 20:51
0

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.

protected by gnat Dec 11 '14 at 17:34

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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