Path: csiph.com!au2pb.net!feeder.erje.net!1.eu.feeder.erje.net!news.swapon.de!aioe.org!.POSTED!not-for-mail
From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk>
Newsgroups: comp.lang.java.programmer
Subject: Re: Never using booleans as parameters
Date: Sun, 22 Nov 2015 14:01:07 -0500
Organization: Aioe.org NNTP Server
Lines: 125
Message-ID: <n2t3di$9lb$1@speranza.aioe.org>
References: <87lh9tysy8.fsf@Equus.decebal.nl>
NNTP-Posting-Host: 1lM8B9/qdtKBc/uIRK2Gjw.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
X-Notice: Filtered by postfilter v. 0.8.2
Xref: csiph.com comp.lang.java.programmer:33179

On 11/20/2015 3:29 AM, Cecil Westerhof 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?

As already pointed out by others then sending boolean as parameters
are widely used.

But it is true that there are some criticism of the construct at
what I would call "the finer theoretical level".

The criticism goes primarily on the fact that a boolean parameter
indicate that the method does two different things and that it
should be split up in two different methods due to that.

And in theory that is a valid argument.

But if we move into the more practical world, then it becomes
less clear in my opinion.

I would distinguish between scenarios where it is different
main logic and scenarios where it is just some
auxiliary functionality.

public void foobar(int n, String s, boolean flag) {
     if(flag) {
         // 10 lines of code
     } else {
         // 10 lines of code
     }
}

indeed look like a suspicious design and should be done as:

public void foobarTrue(int n, String s) {
     // 10 lines of code
}
public void foobarFalse(int n, String s) {
     // 10 lines of code
}

But another example:

public void foobar(int n, String s, boolean flag) {
     // 5 lines of code
     if(flag) {
          // 1 line of code
     }
     // 5 lines of code
     if(flag) {
         // 1 line of code
     }
     // 5 lines of code
}

does not look so bad.

In fact I think it is better than:

public void foobarTrue(int n, String s) {
     // 5 lines of code
     // 1 line of code
     // 5 lines of code
     // 1 line of code
     // 5 lines of code
}
public void foobarFalse(int n, String s) {
     // 5 lines of code
     // 5 lines of code
     // 5 lines of code
}

as that one duplicates too much code.

Someone then recommend:

public void foobarTrue(int n, String s) {
     foobar(n, s, true);
}
public void foobarFalse(int n, String s) {
     foobar(n, s, false);
}
private foobar(int n, String s, boolean flag) {
     // 5 lines of code
     if(flag) {
         // 1 line of code
     }
     // 5 lines of code
     if(flag) {
         // 1 line of code
     }
     // 5 lines of code
}

But I am not buying into that paradigm of designing method
API differently depending on visibility.

So from a pragmatic perspective then I would say that it
depends.

For your verbose flag triggering logging I don't see it as
a problem.

Arne