5

Lets say I have class foo in which I have a Boolean (not boolean) variable bar:

class foo {
    Boolean bar;

    Boolean isBar(){
        return bar;
    }

    boolean isBar(){
        return bar.booleanValue();
    }
}

Which of the above methods is the right way in Java.

I know both will work but I want to know what is the coding convention in Java regarding this matter?

jensgram
  • 31,109
  • 6
  • 81
  • 98
Raheel
  • 4,953
  • 4
  • 34
  • 40
  • 8
    Well do you *want* to return `Boolean` or `boolean`? If you're returning `boolean`, how would you handle `bar` being `null`? – Jon Skeet Jun 13 '13 at 07:39

3 Answers3

11

if you will actualy be using the Boolean type your method should be

Boolean getBar(){
    return bar;
}

otherwise your field should be the primitive boolean type.

G-Man
  • 1,321
  • 8
  • 15
  • 3
    He's not asking for name conventions. He's asking `bar.booleanValue();` vs `return bar;`. It's a good note, but it doesn't answer the question. (Or I misunderstood the question :)) – Maroun Jun 13 '13 at 07:43
  • 2
    Getters for booleans can be prefixed with either `get` or `is`, so the naming is ok, but that's not what he's asking. – Gabriel Negut Jun 13 '13 at 07:44
  • [This question](http://stackoverflow.com/questions/5322648/for-a-boolean-field-what-is-the-naming-convention-for-its-getter-setter) discusses that point and recommends using `isX`... as would I. – selig Jun 13 '13 at 07:46
  • 2
    I think "getBar" is more appropriate here,as Boolean is explicitly an object and also can be "null". It's not about true or false here, it's about true, false and "no state" ;) – Adrian Jun 13 '13 at 07:47
  • 2
    you guys are right, i did interpret the question wrong, changed the answer accordingly. As for naming convention, imho, primitve booleans should be prefixed "is","should" or can. Object Booleans should be prefixed with get. – G-Man Jun 13 '13 at 07:51
3

a boolean is a primitive, it can be true or false. Boolean is an object wrapper for boolean. Boolean can be true, false and null. Unless you need this null, use boolean since it's cheaper for memory.

Boolean has many helper methods, for example, you can have a Boolean from a String by using Boolean.valueOf(theString); which can be "false" or "true", instead of doing

if("true".equals(theString)) 
    primitiveBoolean = true;
Maroun
  • 94,125
  • 30
  • 188
  • 241
2

Unless bar can be null, and this is something you want to model in your class, I would use:

class foo {
    boolean bar;

    boolean isBar(){
        return bar;
    }
}

It's simpler, faster and can't have NullPointerExceptions.

If, however, null is a valid value and you want model that, you should use Boolean/Boolean.

Note that your code:

Boolean bar;

boolean isBar() {
    return bar.booleanValue();
}

Or even the autoboxing variant:

Boolean bar;

boolean isBar() {
    return bar;
}

...may throw NullPointerExceptions. Especially the last one is very confusing.

Harald K
  • 26,314
  • 7
  • 65
  • 111
  • 1
    Good point - what is the reason for having `Boolean` as the instance variable anyway? – selig Jun 13 '13 at 07:47
  • 2
    Boolean as an Object is a "good" way to have 3 states, for instance "On", "Off" and "Doesn't Matter" – Adrian Jun 13 '13 at 07:51
  • 1
    @Adrian, G-Man: Yes, this is what I tried to express with if "null is a valid value and you want model that" – Harald K Jun 13 '13 at 07:53