Groups > comp.lang.java.programmer > #33373

Re: Never using booleans as parameters

From	Brixomatic <brixomatic@yahoo.com>
Newsgroups	comp.lang.java.programmer
Subject	Re: Never using booleans as parameters
Date	2015-12-20 15:44 +0100
Organization	Aioe.org NNTP Server
Message-ID	<MPG.30e0dd2a49c4590e9896ab@news.aioe.org> (permalink)
References	<87lh9tysy8.fsf@Equus.decebal.nl> <MPG.30c53950e81a53589896a7@news.aioe.org> <n46p5b188kddl5h4jvtghhd531bka8iuio@4ax.com>

Show all headers | View raw

In article <n46p5b188kddl5h4jvtghhd531bka8iuio@4ax.com>, Gene Wirchenko 
(genew@telus.net) says...

> >https://brixomatic.wordpress.com/2010/02/24/boolean-harmful/
> >
> >The point I'm making there is comparable to your initial stuff.
> >What if you one day discover that you'll need three levels of verbosity?
> 
>      And what if I know that I will not need the complexity?  (YAGNI.)

As long as it makes the program more readable (the call sites that is), 
you are gonna need it.

>      If I have an enumeration, now I have to check for the added case
> of the parameter value being invalid.  With a boolean, an
> if-then[-else] would do.

1) If you have an if/then, you can't add a case in the first place, 
you'd have to rewrite anyway - which breaks any call site, which is 
shit.

2) You enhance your enum, you don't break any call site - which is good. 
If you reuse your enumeration for differet method definitions and 
doesn't make sense one of those, guard it, like you would normally do, 
if you needed more than one state.

3) The number of call sites usually outnumbers the number of 
definitions, so that is not be a concern in terms of effort (and it also 
isn't compared to any other more-than-2-state logic).

4) It's often good to keep the enumeration local to the class, even if 
you might think you repeat yourself, you might be wrong. Think of: 
HarryPotter#spell vs Muggle#spell ).

5) Your compiler settings, or your static style checker can tell you 
that you missed a case, if you're scared of missing a case after 
enhancing your enum. This is no excuse.

> >And how does 
> > compareObject(a,b, false)
> > compareObject(a,b, true)
> >read compared to 
> > compareObject(a,b, Log.Nothing)
> > compareObject(a,b, Log.Differences)
> >
> >One of the bottom lines is that for the reader "true" or "false" could 
> >mean everything and if you can write code so it requires no 
> >documentation you're generally better off.
> 
>      What I dislike about Log.Nothing, Log.Differences, and similar is
> that so many people confuse them for documentation.  Without anything
> else, I still have to guess what parameter values mean.

Code IS documentation, if properly written.
 
>      Log.Nothing probably means to not log anything at all, but
> Log.Differences states nothing about how those differences are logged
> and if I need to know that, I am out of luck.

You might add a javadoc, if you need closer information. You might also 
be more specific naming the enumeration, which is usually the better 
idea, if it's short.
Log.DifferencesIgnoringWhitespace may be what you want, if you need to 
differentiate further.
I've named comparators like "IName.CompareLexicalLocalizedNullLow" for 
that matter, that doesn't leave much to desire for documentation.

>      Of course, if someone changes the behaviour but not the
> enumeration name, all bets are off.

Same happens with booleans, even worse: Booleans can mean anything, but 
with an enumeration, the changed behaviour will still be somewhat close 
to what the enum says, if the programmer is no complete moron.

>  Log.Nothing might now mean to log
> nothing except for the new classes.

If it is a public API and you're very careful about not breaking any 
user code (like you would in a new JDK version), introduce a new enum 
that says what it does: Log.OnlyNewClasses.

If it is a public API and you're rolling out a new major version that 
breaks compatibility elsewhere anyways, rename and document for release.

If it is your only alternative option besides "Log.Differences" and the 
API is internal, do it like Captain Picard would command you: Name it 
so.

If you create an API and want to be rather liberal to change the 
behaviour little later, be less specific in the first place:
Log.MinimalInformation
Any of these options is better than a boolean that gives you no 
information whatsoever, and changing the behavior will for sure not be 
apparent anywhere. Also consider: Changing the behavior behind a boolean 
argument may be refölected in the method's javadoc, but if people used 
it for a while they will assume they know what they're doing and they 
won't re-read the documentation and fall in the same trap that you have 
if you secretly change the behavior behind the enum.

Kind regards,
-Wanja-


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

Thread

Never using booleans as parameters Cecil Westerhof <Cecil@decebal.nl> - 2015-11-20 09:29 +0100
  Re: Never using booleans as parameters Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-20 11:54 +0000
  Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 08:30 -0500
    Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-11-20 05:57 -0800
      Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 09:17 -0500
  Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-11-20 05:34 -0800
  Re: Never using booleans as parameters Silvio <silvio@internet.com> - 2015-11-20 18:18 +0100
    Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 16:08 -0500
      Re: Never using booleans as parameters Silvio <silvio@internet.com> - 2015-11-23 14:12 +0100
        Re: Never using booleans as parameters Silvio <silvio@internet.com> - 2015-11-23 14:23 +0100
          Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-23 08:42 -0500
            Re: Never using booleans as parameters Silvio <silvio@internet.com> - 2015-11-23 15:14 +0100
        Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-11-23 06:10 -0800
          Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 15:45 -0500
            Re: Never using booleans as parameters Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-30 00:08 +0000
              Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 19:32 -0500
              Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 19:39 -0500
              Re: Never using booleans as parameters Brixomatic <brixomatic@yahoo.com> - 2015-12-20 15:08 +0100
                Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-12-21 05:00 -0800
                Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-21 08:53 -0500
            Re: Never using booleans as parameters Gene Wirchenko <genew@telus.net> - 2015-11-30 10:33 -0800
              Re: Never using booleans as parameters Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2015-12-02 15:51 +0200
      Re: Never using booleans as parameters Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-11-23 21:55 -0800
        Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-24 08:23 -0500
          Re: Never using booleans as parameters Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-11-27 22:52 -0800
        Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 15:55 -0500
  Re: Never using booleans as parameters leif.roar@dimnakorr.com - 2015-11-20 11:44 -0600
    Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-11-20 10:08 -0800
    Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-22 14:03 -0500
  Re: Never using booleans as parameters Gene Wirchenko <genew@telus.net> - 2015-11-20 10:14 -0800
    Re: Never using booleans as parameters Eternal Hope <laughingspam99@gmail.com> - 2015-11-22 14:27 +0000
  Re: Never using booleans as parameters Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2015-11-20 20:13 -0800
    Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-11-23 04:59 -0800
      Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 15:53 -0500
  Re: Never using booleans as parameters galt_57@hotmail.com - 2015-11-22 09:02 -0800
    Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-22 12:20 -0500
  Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-22 12:41 -0500
    Re: Never using booleans as parameters Martin Gregorie <martin@address-in-sig.invalid> - 2015-11-22 18:06 +0000
    Re: Never using booleans as parameters Gene Wirchenko <genew@telus.net> - 2015-11-25 14:21 -0800
      Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 15:58 -0500
        Re: Never using booleans as parameters Gene Wirchenko <genew@telus.net> - 2015-11-30 10:39 -0800
    Re: Never using booleans as parameters Brixomatic <brixomatic@yahoo.com> - 2015-11-29 16:40 +0100
      Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 16:00 -0500
        Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 19:26 -0500
          Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-11-30 06:16 -0800
  Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-22 14:01 -0500
  Re: Never using booleans as parameters Fredrik Jonson <fredrik@jonson.org> - 2015-11-24 18:50 +0000
  Re: Never using booleans as parameters Sir Hugh Jarce <hugh@example.com> - 2015-11-27 10:07 +0000
    Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 15:49 -0500
  Re: Never using booleans as parameters Brixomatic <brixomatic@yahoo.com> - 2015-11-29 16:33 +0100
    Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-29 15:57 -0500
      Re: Never using booleans as parameters Arne Vajhøj <arne@vajhoej.dk> - 2015-11-29 16:01 -0500
      Re: Never using booleans as parameters Brixomatic <brixomatic@yahoo.com> - 2015-12-20 15:00 +0100
        Re: Never using booleans as parameters Gene Wirchenko <genew@telus.net> - 2015-12-21 10:50 -0800
    Re: Never using booleans as parameters Gene Wirchenko <genew@telus.net> - 2015-11-30 10:48 -0800
      Re: Never using booleans as parameters Brixomatic <brixomatic@yahoo.com> - 2015-12-20 15:44 +0100
        Re: Never using booleans as parameters Gene Wirchenko <genew@telus.net> - 2015-12-21 10:56 -0800
        Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-21 15:30 -0500
          Re: Never using booleans as parameters Eric Douglas <e.d.programmer@gmail.com> - 2015-12-21 12:47 -0800
            Re: Never using booleans as parameters Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-21 16:29 -0500

csiph-web