Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33149 > unrolled thread

Never using booleans as parameters

Back to article view | Back to comp.lang.java.programmer

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#33249

On Sun, 29 Nov 2015 15:45:39 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 11/23/2015 9:10 AM, Eric Douglas wrote:

[snip]

>> You could do that, or write it with a comment as such, only if the
> > meaning of the parameters would not be obvious to someone asked to
> > maintain your code later.
>>
>> // beginIndex (zero-based), endIndex
>> y = x.substring(0,4)
>
>Documenting something like this is an indication of a problem
>in my opinion.

     But documenting something as 0-based when that is unusual would
be a good idea.  (I know that it is not that here.)

>Commenting about what the code does is usually a bad sign - good
>comments explains why the code is doing it.

     Generally, yes, with two exceptions IME:

  1) I will break up some code into sections commented with
Initialisation, Open Files, Main Loop, Clean up, Termination, and the
like.  It is easier dealing with smaller pieces than parsing the whole
thing, especially when I am in the middle of maintenance changes.
("Where is clitot initialised?")

  2) Unusual cases that might not be obvious.

>> Of course they should already be able to figure out the parameters
>> from the code complete if they edit this code with a proper IDE.
>
>A good IDE solves many problems.
>
>But I don't like the idea of the readability of code
>being dependent on it.

     Yes.  The problem with something being handled automatically is
that people usually quit handling it themselves.  Then, when an
unusual case happens and the tool does not handle it, the thing does
not get handled.  Fireworks may ensue.

Sincerely,

Gene wirchenko

[toc] | [prev] | [next] | [standalone]

#33266

Gene Wirchenko <genew@telus.net> writes:
> On Sun, 29 Nov 2015 15:45:39 -0500, Arne Vajhøj <arne@vajhoej.dk>
>>On 11/23/2015 9:10 AM, Eric Douglas wrote:

>>> // beginIndex (zero-based), endIndex
>>> y = x.substring(0,4)

>>Documenting something like this is an indication of a problem
>>in my opinion.

>      But documenting something as 0-based when that is unusual would
> be a good idea.  (I know that it is not that here.)

Documenting whether something is 0-based or 1-based is ALWAYS a good
idea, no matter which one is usual in which case.

-- 
Jukka Lahtinen

[toc] | [prev] | [next] | [standalone]

#33188

In article <n2o1vd$os2$1@dont-email.me>,
 Eric Sosman <esosman@comcast-dot-net.invalid> wrote:

 . . .
> 
>      Sometimes, a plain `boolean' is enough documentation:
> 
> 	JFrame frame = ...;
> 	...
> 	frame.setVisible(true);  // not much doubt here
> 
>      Sometimes, the boolean's meaning is not so clear:
> 
> 	HTMLEditorKit.Parser parser = ...;
> 	Reader reader = ...;
> 	HTMLEditorKit.ParserCallback callback = ...;
> 	parser.parse(reader, callback, false);  // WTF?
> 
>      The third argument to parse() would have been better as an
> enum -- but Java didn't have enum's when that API was written.
> Cecil Westerhof's suggestion could help:
> 

Or you can go with an IDE and well documented code so that you always 
know what parameters and methods do just by pointing to them.  You gotta 
have the proper tools of the trade.

I hate working with people coding from crude syntax coloring apps 
because refactoring and cleanup is so much effort for them that they 
don't do it.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

#33192

On 11/24/2015 12:55 AM, Kevin McMurtrie wrote:
> In article <n2o1vd$os2$1@dont-email.me>,
>   Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>
>   . . .
>>
>>       Sometimes, a plain `boolean' is enough documentation:
>>
>> 	JFrame frame = ...;
>> 	...
>> 	frame.setVisible(true);  // not much doubt here
>>
>>       Sometimes, the boolean's meaning is not so clear:
>>
>> 	HTMLEditorKit.Parser parser = ...;
>> 	Reader reader = ...;
>> 	HTMLEditorKit.ParserCallback callback = ...;
>> 	parser.parse(reader, callback, false);  // WTF?
>>
>>       The third argument to parse() would have been better as an
>> enum -- but Java didn't have enum's when that API was written.
>> Cecil Westerhof's suggestion could help:
>
> Or you can go with an IDE and well documented code so that you always
> know what parameters and methods do just by pointing to them.  You gotta
> have the proper tools of the trade.

     Here is an ASCII rendering of the Javadoc for this method:

	public abstract void parse(Reader r,
                            HTMLEditorKit.ParserCallback cb,
                            boolean ignoreCharSet)
                     throws IOException

	Parse the given stream and drive the given callback with the
	results of the parse. This method should be implemented to be
	thread-safe.

	Throws:
	    IOException

... and that's IT.  The boolean parameter has no documentation beyond
its name; in fact, none of the three parameters is documented.  Unless
the IDE has its own private and more complete documentation to draw
upon, it will have very little explanatory power.

> I hate working with people coding from crude syntax coloring apps
> because refactoring and cleanup is so much effort for them that they
> don't do it.

     "Crude?"  Ye gods!  Something in me would just love to see what
a few hours' struggling with a keypunch would do to your attitudes ...
You don't know how good you've got it, laddie.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33220

In article <n31o84$umj$1@dont-email.me>,
 Eric Sosman <esosman@comcast-dot-net.invalid> wrote:

> On 11/24/2015 12:55 AM, Kevin McMurtrie wrote:
> > In article <n2o1vd$os2$1@dont-email.me>,
> >   Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> >
> >   . . .
> >>
> >>       Sometimes, a plain `boolean' is enough documentation:
> >>
> >> 	JFrame frame = ...;
> >> 	...
> >> 	frame.setVisible(true);  // not much doubt here
> >>
> >>       Sometimes, the boolean's meaning is not so clear:
> >>
> >> 	HTMLEditorKit.Parser parser = ...;
> >> 	Reader reader = ...;
> >> 	HTMLEditorKit.ParserCallback callback = ...;
> >> 	parser.parse(reader, callback, false);  // WTF?
> >>
> >>       The third argument to parse() would have been better as an
> >> enum -- but Java didn't have enum's when that API was written.
> >> Cecil Westerhof's suggestion could help:
> >
> > Or you can go with an IDE and well documented code so that you always
> > know what parameters and methods do just by pointing to them.  You gotta
> > have the proper tools of the trade.
> 
>      Here is an ASCII rendering of the Javadoc for this method:
> 
> 	public abstract void parse(Reader r,
>                             HTMLEditorKit.ParserCallback cb,
>                             boolean ignoreCharSet)
>                      throws IOException
> 
> 	Parse the given stream and drive the given callback with the
> 	results of the parse. This method should be implemented to be
> 	thread-safe.
> 
> 	Throws:
> 	    IOException
> 
> ... and that's IT.  The boolean parameter has no documentation beyond
> its name; in fact, none of the three parameters is documented.  Unless
> the IDE has its own private and more complete documentation to draw
> upon, it will have very little explanatory power.

Looks fine to me.  If I need to know the innards, I could hit meta-t in 
Eclipse to see various implementations.

 
> > I hate working with people coding from crude syntax coloring apps
> > because refactoring and cleanup is so much effort for them that they
> > don't do it.
> 
>      "Crude?"  Ye gods!  Something in me would just love to see what
> a few hours' struggling with a keypunch would do to your attitudes ...
> You don't know how good you've got it, laddie.

I used to write programs with a chart of hexadecimal codes for CPU 
instructions.  There was a time for that just as there was a time for 
syntax highlighters.  The scale of typical computer programs has moved 
way beyond that.  It's very difficult to get both the big picture and 
the small details correct without an IDE today.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

#33230

On 11/24/2015 12:55 AM, Kevin McMurtrie wrote:
> Or you can go with an IDE and well documented code so that you always
> know what parameters and methods do just by pointing to them.  You gotta
> have the proper tools of the trade.

Yes. But it can be dangerous to rely too heavily on them.

Imagine getting a printout of the code.

"Sorry I can't read this due to no mouse over"

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#33162

Cecil Westerhof <Cecil@decebal.nl> wrote:
> Often is said that you should never use booleans as parameters. But I
> have a function compareObjects that takes two objects and a boolean
> that signifies if the function is verbose. (Sends logging.)
> 
> I could of-course define compareObjects and compareObjectsVerbose and
> instead of writing:
>    compareObjects(a, b, useVerbose);

If this is a private method, that's perfectly fine, but if it's a method
that's part of an API, I'd probably want to do it like this:

Enum LoggingVerbosity {
  NONE,
  VERBOSE;
}


boolean compareObjects( T a, T b ) {
  return compareObjects( a, b, LoggingVerbosity.NONE );
}

boolean compareObjects( T a, T b, LoggingVerbosity verbosity ) {
  switch( verbosity ) {
    case NONE: ...
    case VERBOSE: ...
    default throw new ProgrammingError( "Unhandled LoggingVerbosity type " + verbosity 
        + " encountered in switch statement. This should not happen." );
  }
}




-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#33163

On Friday, November 20, 2015 at 12:44:49 PM UTC-5, leif...@dimnakorr.com wrote:
> If this is a private method, that's perfectly fine, but if it's a method
> that's part of an API, I'd probably want to do it like this:
> 
> Enum LoggingVerbosity {
>   NONE,
>   VERBOSE;
> }
> 
> 
> boolean compareObjects( T a, T b ) {
>   return compareObjects( a, b, LoggingVerbosity.NONE );
> }
> 
> boolean compareObjects( T a, T b, LoggingVerbosity verbosity ) {
>   switch( verbosity ) {
>     case NONE: ...
>     case VERBOSE: ...
>     default throw new ProgrammingError( "Unhandled LoggingVerbosity type " + verbosity 
>         + " encountered in switch statement. This should not happen." );
>   }
> }

enum should be your best option if it needs or ever might need a different value.  If it will only ever be true or false I'd stick with the boolean.

[toc] | [prev] | [next] | [standalone]

#33180

On 11/20/2015 12:44 PM, leif.roar@dimnakorr.com wrote:
> Cecil Westerhof <Cecil@decebal.nl> wrote:
>> Often is said that you should never use booleans as parameters. But I
>> have a function compareObjects that takes two objects and a boolean
>> that signifies if the function is verbose. (Sends logging.)
>>
>> I could of-course define compareObjects and compareObjectsVerbose and
>> instead of writing:
>>     compareObjects(a, b, useVerbose);
>
> If this is a private method, that's perfectly fine, but if it's a method
> that's part of an API, I'd probably want to do it like this:
>
> Enum LoggingVerbosity {
>    NONE,
>    VERBOSE;
> }
>
>
> boolean compareObjects( T a, T b ) {
>    return compareObjects( a, b, LoggingVerbosity.NONE );
> }
>
> boolean compareObjects( T a, T b, LoggingVerbosity verbosity ) {
>    switch( verbosity ) {
>      case NONE: ...
>      case VERBOSE: ...
>      default throw new ProgrammingError( "Unhandled LoggingVerbosity type " + verbosity
>          + " encountered in switch statement. This should not happen." );
>    }
> }

That is a very valid point.

boolean only have two value's so if the number of values could increase
later then boolean should not be used and enum is the type safe way of
doing that compared to int constants.

Arne

[toc] | [prev] | [next] | [standalone]

#33164

On Fri, 20 Nov 2015 09:29:35 +0100, Cecil Westerhof <Cecil@decebal.nl>
wrote:

>Often is said that you should never use booleans as parameters. But I

     Often stated are various silly rules.  This is one of them.

     When I need to pass a flag to a procedure, I will use a boolean.
Should this report include the detail or not?  I use a boolean. Should
it include the recap subreport or not?  I use a boolean.  I think you
get the picture.

     If it makes sense to use a boolean, use a boolean.  If not, then
do not.

     It is sometimes difficult to figure out why someone ever thought
one of these rules was necessary.  If you are applying rules without
understanding why, that is cargo cult programming.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#33174

On 20/11/2015 18:14, Gene Wirchenko wrote:
> On Fri, 20 Nov 2015 09:29:35 +0100, Cecil Westerhof <Cecil@decebal.nl>
> wrote:
>
>> Often is said that you should never use booleans as parameters. But I
>
>       Often stated are various silly rules.  This is one of them.
>
>       When I need to pass a flag to a procedure, I will use a boolean.
> Should this report include the detail or not?  I use a boolean. Should
> it include the recap subreport or not?  I use a boolean.  I think you
> get the picture.
>
>       If it makes sense to use a boolean, use a boolean.  If not, then
> do not.
>
>       It is sometimes difficult to figure out why someone ever thought
> one of these rules was necessary.

Concur.

Sometimes I think people dream up these rules because they have nothing 
better to do, software development is hard enough without introducing 
all sorts of spurious rules and regulations.

I haven't seen a single argument here that supports the original assertion.


If you are applying rules without
> understanding why, that is cargo cult programming.
>
> [snip]
>
> Sincerely,
>
> Gene Wirchenko
>


-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]

#33173

In article <87lh9tysy8.fsf@Equus.decebal.nl>,
 Cecil Westerhof <Cecil@decebal.nl> wrote:

> Often is said that you should never use booleans as parameters. But I
> have a function compareObjects that takes two objects and a boolean
> that signifies if the function is verbose. (Sends logging.)
> 
> I could of-course define compareObjects and compareObjectsVerbose and
> instead of writing:
>     compareObjects(a, b, useVerbose);
> I could write:
>     if (useVerbose) {
>         compareObjectsVerbose(a, b);
>     } else {
>         compareObjects(a, b);
>     }
> 
> But I do not find that cleaner code. But that could because I am not
> used to it. Would the second manner be better?


Many preached designs of today become tomorrow's anti-patterns.  Do 
whatever makes the code elegant.  Efficiency and maintainability usually 
follows naturally.

In your example above, that if-else block being all over the place would 
annoy me.  A boolean parameter would be cleaner.

On the other hand, you shouldn't accept a big pile of boolean parameters 
unless every permutation is valid and common.  Having unused 
permutations means that the parameters aren't doing a good job of 
modeling the input.  Typical fixes would be switching to enums or 
splitting the method.

-- 
I will not see posts from astraweb, theremailer, dizum, or google
because they host Usenet flooders.

[toc] | [prev] | [next] | [standalone]

#33181

On Friday, November 20, 2015 at 11:20:22 PM UTC-5, Kevin McMurtrie wrote:
> On the other hand, you shouldn't accept a big pile of boolean parameters 
> unless every permutation is valid and common.  Having unused 
> permutations means that the parameters aren't doing a good job of 
> modeling the input.  Typical fixes would be switching to enums or 
> splitting the method.

Splitting up the method entirely is annoying if you'd need to call both these methods frequently but is most efficient if there's a chance you deprecate the boolean value:
<class variable>
boolean verbosity = false;
public void setVerbosity(boolean value)
{verbosity=value}
public boolean compareObjects(Object a,Object b)

If the value is stand-alone you can deprecate and make it do nothing.  If it's a parameter/overload you have to live with it as part of this method, or possibly other methods, or make someone change a lot of code.

[toc] | [prev] | [next] | [standalone]

#33229

On 11/23/2015 9:20 AM, Stefan Ram wrote:
> Eric Douglas <e.d.programmer@gmail.com> writes:
>> If the value is stand-alone you can deprecate and make it do nothing.
>
>    The methods of programming languages were designed after the
>    model of mathematical functions.

I think that is an oversimplification.

void methods and methods with arguments being mutated does
not fit the math function paradigm.

>    In the case of mathematical functions, we do rarely wonder about
>    the meaning of the argument in
>
> y = squareroot( 4 );
>
>    . What is the meaning of »4« here? - The answer is obvious.
>
>    Maybe this is so, because we invested more time in school to learn
>    the meaning of »squareroot« than to learn the meaning of »substring«
>    and because the meaning of »substring« differs across programming
>    languages? Can we learn anything from mathematical functions to make
>    Java method calls more readable?

The number of math functions you can recognize is probably in
the hundreds.

The number of methods in Java with Java EE and a few common libraries
are in the hundreds of thousands.

Big practical difference.

Arne

PS: You are right about substring - language/library designers
     have really screwed that one up big time.

[toc] | [prev] | [next] | [standalone]

#33175

On Friday, November 20, 2015 at 2:44:11 AM UTC-6, Cecil Westerhof wrote:
>
> Often is said that you should never use booleans as parameters. 

Said by who? They are widely used as parameters.

[toc] | [prev] | [next] | [standalone]

#33176

On 11/22/2015 12:02 PM, galt_57@hotmail.com wrote:
> On Friday, November 20, 2015 at 2:44:11 AM UTC-6, Cecil Westerhof wrote:
>> Often is said that you should never use booleans as parameters.
>
> Said by who?

Examples:

http://martinfowler.com/bliki/FlagArgument.html

http://www.informit.com/articles/article.aspx?p=1392524

only two but Martin Fowler and Robert Martin are "names".

>               They are widely used as parameters.

Yes.

Arne

[toc] | [prev] | [next] | [standalone]

#33177

On 11/20/2015 12:17 PM, Stefan Ram wrote:
> Cecil Westerhof <Cecil@decebal.nl> writes:
>> compareObjects(a, b, useVerbose);
>
>    That's alright. Just don't use boolean
>    literals, such as:
>
>        compareObjects( a, b, false );
>
>    . Instead write:
>
>        { final boolean verbose = false;
>          compareObjects( a, b, verbose ); }

The literals question is not specific for boolean at all.

engine.process(1, false);

is difficult to read (you either need to remember what those
parameters means or rely on an IDE to provide the information
as mouse over), but the int is just as difficult to read as
the boolean.

Furthermore the solution specified is not optimal in my opinion.

The best solution is probably the classic:

private static final int ONE_THREAD = 1;
private static final boolean VERBOSE_OFF = false;
...
engine.process(ONE_THREAD, VERBOSE_OFF);

as it documents what the parameters are.

final int ONE_THREAD = 1;
final boolean VERBOSE_OFF = false;
engine.process(ONE_THREAD, VERBOSE_OFF);

is not as good in my opinion. For two reasons:
1) it adds extra unnecessary lines to what the reader have
    to read when reading the code
2) it is not (as) ready for using the same value for multiple
    method calls

Note that the readability argument against literals
can be almost eliminated by a different design:

engine.setThreads(1);
engine.setVerbose(false);
engine.process();

Some will still dislike the literals, but I do not see a readability
issue.

The arguments against the construct will be the reusability and
the consistency.

But I do not see that construct as really bad.

Note that many other languages allows named parameters
to do the same.

Syntax like:

engine.process(threads := 1, verbose := false);

Arne

[toc] | [prev] | [next] | [standalone]

#33178

On Sun, 22 Nov 2015 12:41:14 -0500, Arne Vajhøj wrote:

> On 11/20/2015 12:17 PM, Stefan Ram wrote:
>> Cecil Westerhof <Cecil@decebal.nl> writes:
>>> compareObjects(a, b, useVerbose);
>>
>>    That's alright. Just don't use boolean literals, such as:
>>
>>        compareObjects( a, b, false );
>>
>>    . Instead write:
>>
>>        { final boolean verbose = false;
>>          compareObjects( a, b, verbose ); }
> 
> The literals question is not specific for boolean at all.
> 
> engine.process(1, false);
> 
> is difficult to read (you either need to remember what those parameters
> means or rely on an IDE to provide the information as mouse over), but
> the int is just as difficult to read as the boolean.
> 
> Furthermore the solution specified is not optimal in my opinion.
> 
> The best solution is probably the classic:
> 
> private static final int ONE_THREAD = 1;
> private static final boolean VERBOSE_OFF = false;
> ...
> engine.process(ONE_THREAD, VERBOSE_OFF);
> 
> as it documents what the parameters are.
> 
> final int ONE_THREAD = 1;
> final boolean VERBOSE_OFF = false;
> engine.process(ONE_THREAD, VERBOSE_OFF);
> 
> is not as good in my opinion. For two reasons:
> 1) it adds extra unnecessary lines to what the reader have
>     to read when reading the code
> 2) it is not (as) ready for using the same value for multiple
>     method calls
> 
> Note that the readability argument against literals can be almost
> eliminated by a different design:
> 
> engine.setThreads(1);
> engine.setVerbose(false);
> engine.process();
> 
> Some will still dislike the literals, but I do not see a readability
> issue.
> 
> The arguments against the construct will be the reusability and the
> consistency.
> 
> But I do not see that construct as really bad.
> 
> Note that many other languages allows named parameters to do the same.
> 
> Syntax like:
> 
> engine.process(threads := 1, verbose := false);
> 
> Arne

+1

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33204

On Sun, 22 Nov 2015 12:41:14 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

[snip]

>Furthermore the solution specified is not optimal in my opinion.
>
>The best solution is probably the classic:
>
>private static final int ONE_THREAD = 1;
>private static final boolean VERBOSE_OFF = false;
>...
>engine.process(ONE_THREAD, VERBOSE_OFF);
>
>as it documents what the parameters are.
>
>final int ONE_THREAD = 1;
>final boolean VERBOSE_OFF = false;
>engine.process(ONE_THREAD, VERBOSE_OFF);
>
>is not as good in my opinion. For two reasons:
>1) it adds extra unnecessary lines to what the reader have
>    to read when reading the code
>2) it is not (as) ready for using the same value for multiple
>    method calls
>
>Note that the readability argument against literals
>can be almost eliminated by a different design:
>
>engine.setThreads(1);
>engine.setVerbose(false);
>engine.process();
>
>Some will still dislike the literals, but I do not see a readability
>issue.

     Your earlier comment applies:
>1) it adds extra unnecessary lines to what the reader have
>    to read when reading the code

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#33232

On 11/25/2015 5:21 PM, Gene Wirchenko wrote:
> On Sun, 22 Nov 2015 12:41:14 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> final int ONE_THREAD = 1;
>> final boolean VERBOSE_OFF = false;
>> engine.process(ONE_THREAD, VERBOSE_OFF);
>>
>> is not as good in my opinion. For two reasons:
>> 1) it adds extra unnecessary lines to what the reader have
>>     to read when reading the code
>> 2) it is not (as) ready for using the same value for multiple
>>     method calls
>>
>> Note that the readability argument against literals
>> can be almost eliminated by a different design:
>>
>> engine.setThreads(1);
>> engine.setVerbose(false);
>> engine.process();
>>
>> Some will still dislike the literals, but I do not see a readability
>> issue.
>
>       Your earlier comment applies:
>> 1) it adds extra unnecessary lines to what the reader have
>>     to read when reading the code

It sure does add the same number of extra lines.

But the lines contain less repetitive information.

So I think it is slightly better than the local variables.

Arne

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web