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 3 of 3 — ← Prev page 1 2 [3]

#33250

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

>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:

[snip]

>>> 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.

     Which menas that there is more that has to be read.  This is not
an advantage!

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

     I would go with the local variables or literals.  Often, they
make sense in the local context.

Sincerely,

Gene Wirchenko

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

#33226

In article <n2sunp$soh$1@speranza.aioe.org>, Arne Vajhøj 
(arne@vajhoej.dk) says...
what the parameters are.
> 
> final int ONE_THREAD = 1;
> final boolean VERBOSE_OFF = false;
> engine.process(ONE_THREAD, VERBOSE_OFF);

[..]

> Note that the readability argument against literals
> can be almost eliminated by a different design:
> 
> engine.setThreads(1);
> engine.setVerbose(false);
> engine.process();

That is forcing the "engine" to be a mutable object, which I consider a 
design flaw, of you can have otherwise. Especially if you only do that 
so avoid literals.

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]

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

#33233

On 11/29/2015 10:40 AM, Brixomatic wrote:
> In article <n2sunp$soh$1@speranza.aioe.org>, Arne Vajhøj
> (arne@vajhoej.dk) says...
> what the parameters are.
>>
>> final int ONE_THREAD = 1;
>> final boolean VERBOSE_OFF = false;
>> engine.process(ONE_THREAD, VERBOSE_OFF);
>
> [..]
>
>> Note that the readability argument against literals
>> can be almost eliminated by a different design:
>>
>> engine.setThreads(1);
>> engine.setVerbose(false);
>> engine.process();
>
> That is forcing the "engine" to be a mutable object, which I consider a
> design flaw, of you can have otherwise. Especially if you only do that
> so avoid literals.

Lots of classes end up being mutable anyway.

But correct - if it could be unmutable with the arguments then
adding setters does make it mutable and have consequences for
concurrent usage.

Arne

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

#33237

On 11/29/2015 4:17 PM, Stefan Ram wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>> But correct - if it could be unmutable with the arguments then
>> adding setters does make it mutable and have consequences for
>> concurrent usage.
>
>    final Engine engine = new EngineCreator().
>    numberOfThreads( 1 ).noVerboseReporting().create();
>
>    Now I have invented something, wait, I'll give it a name,
>    no, yes, wait, I call it »fluent interface«!

Unless it does a lot of cloning (which I don't think
fluent API's typical do) then that does not solve
Wanja's issue with mutable.

It superficially solve Gene's issue with the extra lines. But
in my opinion then fluent API's need to be very natural
to have a positive impact on readability.

Arne

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

#33247

On Sunday, November 29, 2015 at 7:27:10 PM UTC-5, Arne Vajhøj wrote:
> On 11/29/2015 4:17 PM, Stefan Ram wrote:
> > =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
> >> But correct - if it could be unmutable with the arguments then
> >> adding setters does make it mutable and have consequences for
> >> concurrent usage.
> >
> >    final Engine engine = new EngineCreator().
> >    numberOfThreads( 1 ).noVerboseReporting().create();
> >
> >    Now I have invented something, wait, I'll give it a name,
> >    no, yes, wait, I call it »fluent interface«!
> 
> Unless it does a lot of cloning (which I don't think
> fluent API's typical do) then that does not solve
> Wanja's issue with mutable.
> 
> It superficially solve Gene's issue with the extra lines. But
> in my opinion then fluent API's need to be very natural
> to have a positive impact on readability.
> 
> Arne

Chaining methods seems an odd solution to me.  I use at least one API that does that.

https://developers.google.com/api-client-library/java/google-api-java-client/reference/1.20.0/com/google/api/client/googleapis/auth/oauth2/GoogleCredential.Builder

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

#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

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

#33195

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.)

There is of course always the exception that proves the rule. I find that
design recommendations such as this one exist primarily to make you take a step
back and think again.

In this case there is a easy way out. Most logging libraries have a system
in place to specify loglevels, and that is the way you solve this particular
problem. That is, skip the boolean, and check the runtime loglevel of the 
class or method instead.

import some.logger.LogMamager;
import some.logger.Logger;

public class Foo {
    public static final Logger logger = LogManager.getLogger(Foo.class);

    public doWhatever(Foo bar, Foo baz) {
        if (logger.isDebugEnabled())
        {
            logger.debug("Whatever... ");
        }
        // do whatever
    }
}

If you're not using a logging library, or the library you're using doesn't
support this pattern, you should really stop and reconsider.

https://logging.apache.org/log4j/2.x/
http://www.slf4j.org/
https://developer.android.com/reference/android/util/Log.html
https://docs.oracle.com/javase/8/docs/api/java/util/logging/package-summary.html

-- 
Fredrik Jonson

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

#33211

On 20/11/2015 08:29, 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?
>

I realise this thread has probably run it's course by now but I was just 
wondering how the following class could be made any clearer
by *not* passing a boolean.

The two unparameterised getters are redundant apart from readability issues.

class ConnectionManager{

     public ConnectionManager(){
        //configurable
        //instantiate JDBC driver OR
        //JNDI lookup container managed connection pool
     }

     Connection getConnection(boolean isTransactional){
        ...
     }

     Connection getConnection(){
         return getConnection(false);
     }

     Connection getTransactionalConnection(){
	return getConnection(true);
     }

     ...

     void closeConnection(Connection conn){
     }
}

Hugh

-- 
Live long and prosper.

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

#33228

On 11/27/2015 5:07 AM, Sir Hugh Jarce wrote:
> I realise this thread has probably run it's course by now but I was just
> wondering how the following class could be made any clearer
> by *not* passing a boolean.
>
> The two unparameterised getters are redundant apart from readability
> issues.
>
> class ConnectionManager{
>
>      public ConnectionManager(){
>         //configurable
>         //instantiate JDBC driver OR
>         //JNDI lookup container managed connection pool
>      }
>
>      Connection getConnection(boolean isTransactional){
>         ...
>      }
>
>      Connection getConnection(){
>          return getConnection(false);
>      }
>
>      Connection getTransactionalConnection(){
>      return getConnection(true);
>      }
>
>      ...
>
>      void closeConnection(Connection conn){
>      }
> }

In my opinion it can't.


But some disagree.

If you find my post from the 22nd, then I elaborated a bit
on my view.

Arne

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

#33225

In article <87lh9tysy8.fsf@Equus.decebal.nl>, Cecil Westerhof 
(Cecil@decebal.nl) says...
> 
> 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?


In my opinion boolean parameters suck. 

But since I dislike to repat myself, you might like to read my ramblings 
here. This posting is now almost half a century old and I haven't 
changed my mind to the slightest:

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 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.

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]

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

#33231

On 11/29/2015 10:33 AM, Brixomatic wrote:
> [...] This posting is now almost half a century old and I haven't
> changed my mind to the slightest:
>
> https://brixomatic.wordpress.com/2010/02/24/boolean-harmful/

     2010 to 2015 is "almost half a century?"  You must be one
of those folks who live life in the fast lane ...

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

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

#33234

On 11/29/2015 3:57 PM, Eric Sosman wrote:
> On 11/29/2015 10:33 AM, Brixomatic wrote:
>> [...] This posting is now almost half a century old and I haven't
>> changed my mind to the slightest:
>>
>> https://brixomatic.wordpress.com/2010/02/24/boolean-harmful/
>
>      2010 to 2015 is "almost half a century?"  You must be one
> of those folks who live life in the fast lane ...

I will make a guess that he meant to say decade not century.

:-)

Arne

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

#33371

In article <n3font$qke$1@dont-email.me>, Eric Sosman (esosman@comcast-
dot-net.invalid) says...
> 
> On 11/29/2015 10:33 AM, Brixomatic wrote:
> > [...] This posting is now almost half a century old and I haven't
> > changed my mind to the slightest:
> >
> > https://brixomatic.wordpress.com/2010/02/24/boolean-harmful/
> 
>      2010 to 2015 is "almost half a century?"  You must be one
> of those folks who live life in the fast lane ...

Ooops... decade. My bad.

Kind regards,
one whose native language is not English and occasionally does a 
mistake.

-- 
..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]

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

#33380

On Sun, 20 Dec 2015 15:00:37 +0100, Brixomatic <brixomatic@yahoo.com>
wrote:

>In article <n3font$qke$1@dont-email.me>, Eric Sosman (esosman@comcast-
>dot-net.invalid) says...
>> 
>> On 11/29/2015 10:33 AM, Brixomatic wrote:
>> > [...] This posting is now almost half a century old and I haven't
>> > changed my mind to the slightest:
>> >
>> > https://brixomatic.wordpress.com/2010/02/24/boolean-harmful/
>> 
>>      2010 to 2015 is "almost half a century?"  You must be one
>> of those folks who live life in the fast lane ...
>
>Ooops... decade. My bad.
>
>Kind regards,
>one whose native language is not English and occasionally does a 
>mistake.

     That should be "makes a mistake".  I am fluent only in English
and respect those who know more than one language to reasonable
fluency.  I took French in high school, but I never got the ear for
it.

     I am currently studying Japanese.  Hoo boy!  Some day, I hope to
be as good at it as a chatty three-year-old.  I said this to a woman
at the Japanese-style burger cafe I regularly go to.  I then gave the
example of trying to say "I want a cookie." saying that I did not know
the word for "want".  She gave it to me but in plain (not polite)
form.  I then amended my statement to wanting to be as good as a
*polite* three-year-old.

Sincerely,

Gene Wirchenko

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

#33251

On Sun, 29 Nov 2015 16:33:58 +0100, Brixomatic <brixomatic@yahoo.com>
wrote:

>In article <87lh9tysy8.fsf@Equus.decebal.nl>, Cecil Westerhof 
>(Cecil@decebal.nl) says...
>> 
>> 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?
>
>
>In my opinion boolean parameters suck. 
>
>But since I dislike to repat myself, you might like to read my ramblings 
>here. This posting is now almost half a century old and I haven't 
>changed my mind to the slightest:
>
>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.)

     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.

>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.

     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.

     Of course, if someone changes the behaviour but not the
enumeration name, all bets are off.  Log.Nothing might now mean to log
nothing except for the new classes.

Sincerely,

Gene Wirchenko

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

#33373

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]

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

#33381

On Sun, 20 Dec 2015 15:44:32 +0100, Brixomatic <brixomatic@yahoo.com>
wrote:

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

[snip]

>>      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.

     No, it is not.  Code states how something is done.  It does not
state what is done or why it is done.  Code also gets into all sorts
of complications that can be quite irrelevant to the user.

     When I want to use something, I am usually concerned with what is
being done or why.  I am far less concerned with exactly how it is
implemented, and if I have to dig into the code to figure out stuff,
it is usually a waste of time.

     I want good documentation for programs.  I do not want to have to
take the program apart.  For example, to figure out how to use a
compiler, I would rather read the documentation than read the code.
 
>>      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 

     In which case, the code is not sufficient.

[snip]

Sincerely,

Gene Wirchenko

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

#33382

On 12/20/2015 9:44 AM, Brixomatic wrote:
>[...]
> Code IS documentation, if properly written.

     Corollary: Properly-written code is comment-free.  ;-)

     Corollary II: Languages that support comments encourage
improperly-written code.  :-)

     Only half a :-), though.  Long ago I read of an experiment --
it may have been reported in Weinberg's "The Psychology of Computer
Programming" -- in which computer science students were given other
people's code to debug.  Half the students received the code as it
stood, the others got the code with all comments removed.  The no-
comment group found and fixed more bugs, and faster, than the group
with the "benefit" of the comments.  (It's easy to speculate on the
reasons for this, but speculation is only about, oh, 54.7% reliable.)

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

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

#33383

On Monday, December 21, 2015 at 3:31:05 PM UTC-5, Eric Sosman wrote:
> On 12/20/2015 9:44 AM, Brixomatic wrote:
> >[...]
> > Code IS documentation, if properly written.
> 
>      Corollary: Properly-written code is comment-free.  ;-)
> 
>      Corollary II: Languages that support comments encourage
> improperly-written code.  :-)
> 
>      Only half a :-), though.  Long ago I read of an experiment --
> it may have been reported in Weinberg's "The Psychology of Computer
> Programming" -- in which computer science students were given other
> people's code to debug.  Half the students received the code as it
> stood, the others got the code with all comments removed.  The no-
> comment group found and fixed more bugs, and faster, than the group
> with the "benefit" of the comments.  (It's easy to speculate on the
> reasons for this, but speculation is only about, oh, 54.7% reliable.)

Comment free code that is not self documenting takes up less disk space.
Don't ever use whitespace if whitespace is not required.
All variable names should be as short as possible ie A0,A1,A2.
This is what code looked like just a couple decades ago.

About 71.3% of all statistics are made up on the spot.

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

#33384

On 12/21/2015 3:47 PM, Eric Douglas wrote:
> On Monday, December 21, 2015 at 3:31:05 PM UTC-5, Eric Sosman wrote:
>> On 12/20/2015 9:44 AM, Brixomatic wrote:
>>> [...]
>>> Code IS documentation, if properly written.
>>
>>       Corollary: Properly-written code is comment-free.  ;-)
>>
>>       Corollary II: Languages that support comments encourage
>> improperly-written code.  :-)
>>
>>       Only half a :-), though.  Long ago I read of an experiment --
>> it may have been reported in Weinberg's "The Psychology of Computer
>> Programming" -- in which computer science students were given other
>> people's code to debug.  Half the students received the code as it
>> stood, the others got the code with all comments removed.  The no-
>> comment group found and fixed more bugs, and faster, than the group
>> with the "benefit" of the comments.  (It's easy to speculate on the
>> reasons for this, but speculation is only about, oh, 54.7% reliable.)
>
> Comment free code that is not self documenting takes up less disk space.
> Don't ever use whitespace if whitespace is not required.
> All variable names should be as short as possible ie A0,A1,A2.
> This is what code looked like just a couple decades ago.
>
> About 71.3% of all statistics are made up on the spot.

     Anecdote: In my long-distant Bright College Days, when the school's
only computer filled a room, had an eighth of a megabyte of memory, and
executed about 1e5 instructions per second, a lot of code was written in
assembly language to get the utmost out of limited resources.  Some of
us students earned pocket money by writing things for the Computer
Center, and one guy in particular wrote his stuff with the apparent aim
of minimizing keypunching time (recall that I said "long-distant"):

  ...
  L 0,VARA
  SLA 0,1
  AL 0,VARB
  ST 0,VARC
  ...

     The long-suffering staffer who oversaw us rowdies threw a fit at
this guy's code, and wouldn't accept it.  "Comments! Where are the
comments?  And use equates for the register numbers, so they'll show up
in the cross-reference listing! And line up the columns in the normal
way! Take this crap away, and bring it back when you've done it right!
The back o' me hand to ye, and out of my sight!"

     The student went away and wrote a "TIDY" program for his assembly
code, dumped his original deck through it, and re-submitted:

	R0        EQU    0          SYMBOL FOR REGISTER 0
	R1        EQU    1          SYMBOL FOR REGISTER 1
	...
	R15       EQU    15         SYMBOL FOR REGISTER 15
	...
	          L      R0,VARA    LOAD R0 FROM VARA
	          SLA    R0,1       SHIFT R0 LEFT 1 BIT
	          AL     R0,VARB    ADD VARB TO R0
	          ST     R0,VARC    STORE R0 TO VARC
	...

     The overseer accepted this "fully-commented" code.  It's not clear
whether he simply didn't notice that the comments were meaningless or
realized that expostulation would get him nowhere ...

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

[toc] | [prev] | [standalone]

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

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

csiph-web