question to Roedy and others about boolean testing

Discussion in 'Java' started by Jean Lutrin, May 2, 2004.

  1. Jean Lutrin

    Jean Lutrin Guest

    Hi,

    Roedy, in another thread, you said that I should not write :

    if (someBoolean == true) {...}

    but simply :

    if (someBoolean)

    when working with a boolean primitive.


    However I do find :

    if (!someBoolean) {...}

    to be much less readable than :

    if (someBoolean == false) {...}

    (and this is especially true, at least for me,
    when the boolean has a lloonngg name, like :
    isMD5ChecksumAvailable... it is easy
    to forgot about the "!" or simply not to see
    it, not that I advice using long names btw ;)

    And I know that there are others who prefer to
    use the latter when doing such tests.

    So my 2 Eurocents question is : would it make
    sense in source code to use :

    if (someBoolean) {...}

    when testing for "true" and :

    if (someBoolean == false)

    when testing for false ?

    I have to say we have strong guidelines here
    at work (and I mainly established them, back in
    the days, then refined them based on advices
    given in the chapter in "Bitter Java"
    devoted to this subject) and I would like to
    know what is the "best" way to do it...

    If I'm really motivated I could hack a little
    grep/sed/whatever Unix script on the CVS server
    we now all use (that I set up some weeks ago)
    to see what the developers favor and if they
    are consistent.

    Statistics on this topic anybody ? Or guidelines ?

    Cya later and, as usual, excuse my french ;)

    Jean




    P.S : sometimes it is even clearer, at least
    for me when I read it, to write :

    if (... != true) {...}

    instead of :

    if (... == false) {...}

    It all depends on the circumstances. Btw, it is
    not "just about logic", I think that the fact
    that my mother tongue is french means I "read"
    the "english" code differently than an native
    english speaker... So what may sounds redundant
    for you may just seem "natural" for me. Of
    course, I think that consistency is the most
    important thing and that everybody should do
    the same, because it facilitates team work
    (then again my team is all french-speaking but
    we don't use a single french comment nor a
    single french class/variable/file names :
    our naming convention is ASCII compliant :)
     
    Jean Lutrin, May 2, 2004
    #1
    1. Advertisements

  2. Jean Lutrin

    Roedy Green Guest

    If you write that as

    if ( ! someBoolean ) { ... }

    I think you would find you would not miss the !

    How do you talk to yourself when you read code:

    if ( ! ready )

    I would read as "if not ready"

    if ( ready == false )

    I would read as "if ready is false"

    I find the first more natural.
     
    Roedy Green, May 2, 2004
    #2
    1. Advertisements

  3. Jean Lutrin

    DigiAl Guest

    <snip>


    Surely its whatever you prefer, I understand that its good to be consistent
    but for something like this don't worry about the 'guidelines' but worry
    about how easy it would be for you to debug your code in the future.

    Well that's my 2 pence anyway :)

    alan.
     
    DigiAl, May 2, 2004
    #3
  4. Jean Lutrin

    Chris Uppal Guest

    I'll admit that if I saw:

    if (someBoolean == false)

    in some code, then I wouldn't automatically assume that the author was an idiot
    in the way that I would for:

    if (someBoolean == true)

    but I'd still advise against it.


    One reason is that it leads to a "discontinuity" between how you write the code
    when you are testing for the condition being true and how you write it when the
    condition is false. E.g. I would call the following unacceptably ugly:

    if (someCondition)
    {
    // code
    }
    else if (someOtherCondition == false)
    {
    // more code


    The other reason is that you do, and will, have to read code that doesn't use
    that convention. You've said that you find it relatively difficult to "see"
    the "!", but what that suggests to me is that you need more practise in
    reading code that uses "!", not a systematic attempt to pretend that the
    construction doesn't exist. If you could change the definition of the Java
    language, or at least get enough support from the Java community that
    "condition == false" was the de-facto standard expression, then all well and
    good. But you can't, so I think you'd be better off learning to be comfortable
    with Java as it is commonly written.

    -- chris
     
    Chris Uppal, May 2, 2004
    #4
  5. Jean Lutrin:

    [...]
    I think once you'll have more Java experience using !b instead of b ==
    false will become very natural. It's just a matter of time.

    Besides, almost everybody else is "doing it". That usually isn't
    really the best reason to do things, but whenever other people read
    your code or you read other people's code, there will be some
    confusion because you do it differently. Not much confusion, but the
    more you digress from Sun's coding standards, the more time it will
    take the average developer to understand your code.

    There are other typical code lines you should get used to. Including:

    while ((i = in.read()) != -1) { ... }

    int j = a > 12 ? 4 : 3;

    ....

    There are more verbose and beginner-friendly ("readable") ways of
    expressing these lines, but they are standard and avoiding them may be
    more of a problem than improvement.

    Regards,
    Marco
     
    Marco Schmidt, May 2, 2004
    #5
  6. Jean Lutrin

    Roedy Green Guest

    You have to be consistent, especially on a team. In general, when
    someone shows me a shorter way to express something, that usually does
    it for me. Shorter is better.

    My eyes have enough to take in each day without meaningless
    decoration.
     
    Roedy Green, May 2, 2004
    #6
  7. With if (someBoolean == false) you also run the risk of typing
    if (someBoolean = false).

    PS:
    Most books advice to write a comparison of a variable with a constant as
    if (constant comparator variable)
     
    Tim Van Wassenhove, May 2, 2004
    #7
  8. Well, I find that hard to read :)
    I haven't read that suggestion. What is the basis for it?

    /L
     
    Lasse Reichstein Nielsen, May 2, 2004
    #8
  9. Tim Van Wassenhove:
    But different from C, the Java compiler will complain about that
    because it's not allowed.

    [...]

    Regards,
    Marco
     
    Marco Schmidt, May 2, 2004
    #9
  10. Yes it is. Just try it.
     
    Joona I Palaste, May 2, 2004
    #10
  11. Oh yes it is. Java allows this construct only for boolean types, whereas
    C permits it for other types as well.

    Mark Thornton
     
    Mark Thornton, May 2, 2004
    #11
  12. In fact, C permits it for any type that either is a scalar type (i.e.
    a number of a pointer) or "decays" into a scalar type when used as a
    value.
     
    Joona I Palaste, May 2, 2004
    #12
  13. Confusing typo - I meant a number *or* a pointer.
     
    Joona I Palaste, May 2, 2004
    #13
  14. Joona I Palaste:
    Indeed. Why, oh why? I thought that was one of the things they removed
    because it was such an obvious source of errors? At least in Java you
    can't do the assignment with ints anymore, but that has more to do
    with the fact that there is a strict separation between int and
    boolean.

    Regards,
    Marco
     
    Marco Schmidt, May 2, 2004
    #14
  15. I feel the opposite way. If there are easily defined semantics for
    something, and allowing it doesn't cause any extra work (on the
    contrary, *not* allowing it would cause extra work) then I see no
    harm in allowing it.
    For example, code after an unconditional return, catching exceptions
    that are never thrown, empty statements, etc. Java goes out of its
    way to self-righteously disallow them. I bet JVM implementors actually
    have to insert "special case" code just to disallow those things.
    Now, using a variable that might not have been initialised, *THAT*
    should well and good be disallowed. It makes the program work more
    deterministically.
     
    Joona I Palaste, May 2, 2004
    #15
  16. Joona I Palaste:
    Some constructs make it easier to introduce errors than others.
    Obviously is quite subjective what is readable and what not, so there
    probably won't be a definite answer.

    BTW, just now somebody in the German Java newsgroup sent some code
    asking why it wouldn't work. It includes lines like:

    if (state1 =true &&Integer.parseInt(evt.getActionCommand())==5){

    So that particular Java feature does confuse people. Just an example,
    not a proof, of course.
    You want more freedom, but in these special cases I'm not sure what
    you gain. On the other hand, lots of beginners will probably get more
    insight. Maybe a warning instead of an error would be a nice
    compromise.

    Regards,
    Marco
     
    Marco Schmidt, May 2, 2004
    #16
  17. Yes, I'll settle for warnings, insults, even threats, as long as the
    compiler obediently compiles my code into the correct bytecode.
     
    Joona I Palaste, May 2, 2004
    #17
  18. I don't like it either.

    But, if you try to compile it, the compiler will notice that you are
    trying to assign a value to a constant and complain about that.
     
    Tim Van Wassenhove, May 2, 2004
    #18
  19. Jean Lutrin

    Jean Lutrin Guest

    Hi,

    I think I can answer that one...

    First, in this very special case, when writing :

    if (false == someBooleanVariable) {...}

    you don't risk writing inadvertently :

    if (false = someBooleanVariable) {...}

    The compiler would catch is as soon as possible (actually
    my IDE catch it instantly).

    While if you write :

    if (someBooleanVariable = false) {...}

    it is generally a mistake and would go more or less
    unnoticed.

    Now, having that said, any decent IDE *will*
    help spot such obvious errors (it may be "correct", but
    very often it is a mistake... If I do this inadvertently,
    IntelliJ, for example, warns me that I made an unnecessary
    assignation to someBooleanVariable somewhere else in my
    code. That is just one example).

    Secondly, imagine, for "very large value of 'constant',
    'comparator' and 'variable'" ;) (this may not be exactly
    what Tim had in mind, but it certainly is also true -- I
    think there's a section of "Effective Java" that
    explain this), you have this :


    static final String SOME_PROLIFIC_POSTER = "Roedy";

    String mostFrequentPoster;

    if ( mostFrequentPoster.equals(SOME_PROLIFIC_POSTER)) {...}

    If "mostFrequentPoster" is null, you have a null pointer exception
    (which may, or may not, be a problem).

    While :

    if (SOME_PROLIFIC_POSTER.equals(mostFrequentPoster)) {...}

    will have the correct behaviour if mostFrequentPoster is null...

    Cya all,

    Jean
     
    Jean Lutrin, May 2, 2004
    #19
  20. Jean Lutrin

    Chris Smith Guest

    This got me curious, so I did a search through a current project from
    work to find all occurrences of "== true". I found seven. Six of those
    came from a contractor we had working for us who had a very verbose and
    tedious coding style, but he wasn't really an idiot. The other one I
    wrote. It is:

    if (model.getTrueFalseCorrectAnswer() == true)
    {
    trueButton.setSelected(true);
    }

    It's written that way because it reads better. "true" is a possible
    correct answer for the question. The boolean expression doesn't
    represent a condition that's either true or false. I wonder if you
    object to that.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
     
    Chris Smith, May 2, 2004
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.