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

Groups > comp.programming > #16773 > unrolled thread

“Booleans Considered Harmful”

Back to article view | Back to comp.programming

Contents

  “Booleans Considered Harmful” Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 06:51 +0000
    Re: “Booleans Considered Harmful” Julio Di Egidio <julio@diegidio.name> - 2025-05-22 11:14 +0200
      Re: “Booleans Considered Harmful” Julio Di Egidio <julio@diegidio.name> - 2025-05-22 12:04 +0200
      Re: “Booleans Considered Harmful” Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:33 +0000
        Re: “Booleans Considered Harmful” Julio Di Egidio <julio@diegidio.name> - 2025-05-23 07:04 +0200
    Re: “Booleans Considered Harmful” David Brown <david.brown@hesbynett.no> - 2025-05-22 13:51 +0200
      Re: “Booleans Considered Harmful” Julio Di Egidio <julio@diegidio.name> - 2025-05-22 14:43 +0200
        Re: “Booleans Considered Harmful” Julio Di Egidio <julio@diegidio.name> - 2025-05-22 14:57 +0200
    Re: “Booleans Considered Harmful” Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 12:27 -0700
    Re: “Booleans Considered Harmful” JJ <jj4public@outlook.com> - 2025-05-23 16:56 +0700
      Re: “Booleans Considered Harmful” Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 22:58 +0000
    Re: “Booleans Considered Harmful” Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 22:48 +0000
    Re: “Booleans Considered Harmful” c186282 <c186282@nnada.net> - 2025-06-18 02:40 -0400

#16773 — “Booleans Considered Harmful”

I think most of this article is a load of nonsense, myself.

<https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>

Thoughts?

[toc] | [next] | [standalone]

#16774

On 22/05/2025 08:51, Lawrence D'Oliveiro wrote:

> I think most of this article is a load of nonsense, myself.
> 
> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
> 
> Thoughts?

Yeah, it's mostly balderdash, especially the "think positive"
part: rules of dumb I call those, in fact reinventing the wheel
and reinventing it wrong.

But we know better: the one best practice that would be relevant
there is *do not use magic values*.  And of course we could rather
say more about that.  And of course it still wouldn't be just a
rule of dumb, rather learn the art of incremental/evolutionary...

-Julio

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

#16775

On 22/05/2025 11:14, Julio Di Egidio wrote:
> On 22/05/2025 08:51, Lawrence D'Oliveiro wrote:
> 
>> I think most of this article is a load of nonsense, myself.
>>
>> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
>>
>> Thoughts?
> 
> Yeah, it's mostly balderdash, especially the "think positive"
> part: rules of dumb I call those, in fact reinventing the wheel
> and reinventing it wrong.
> 
> But we know better: the one best practice that would be relevant
> there is *do not use magic values*.  And of course we could rather
> say more about that.  And of course it still wouldn't be just a
> rule of dumb, rather learn the art of *incremental/evolutionary*...

...together with what *readability* even means.

-Julio

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

#16780

On Thu, 22 May 2025 11:14:17 +0200, Julio Di Egidio wrote:

> But we know better: the one best practice that would be relevant there
> is *do not use magic values*.

I think the writer was trying to make a point about cryptic actual-
argument values. But that is an issue that applies to other types besides 
booleans, and is easily solved by passing arguments by keyword. Compare 
his example

    saveUser(user, true, false);

with something more like

    saveUser
      (
        user,
        sendWelcomeEmail := true,
        verified := false
      );

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

#16781

On 23/05/2025 00:33, Lawrence D'Oliveiro wrote:
> On Thu, 22 May 2025 11:14:17 +0200, Julio Di Egidio wrote:
> 
>> But we know better: the one best practice that would be relevant there
>> is *do not use magic values*.
> 
> I think the writer was trying to make a point about

Is this the first time you hear there is something
wrong with the booleans?  And similar stupid shit?

Opinion leaders start some insane and self-serving
bullshit, be it the promotion of the latest magic
positions, or vice versa the bullshitting of whatever
is most sacred of our discipline: and a legion of
blog(ger)s just copies, maybe rephrases, and multiplies.
And a legion of incompetent programmers falls for it.

That's been going on for three decades now.  Indeed,
sorry for the wake up call, but, software-wise, 95%
of all that is available online, from the guidance
to the blogs, is not even wrong to put it charitably.

>      saveUser(user, true, false);
> with something more like

Here is another maxim: you cannot learn anything at
all about writing code from just the 5 liners!  Sure,
you can speculate, ad libitum: which is yet another
way in which all of that is *the exact opposite* of
what one should do in this job.  But just reread my
initial post, it's all already there, what one should
do, and how it fundamentally differs, in level and
direction from what you are chasing there.

And here is rather a tip: how many lines of code have
you read in your entire life?  For some reference,
I think I have spent at least my first 15 years of
profession not just seriously studying (SE) while
conscientiously practising, but also reading/studying
thousands and thousands and thousands of lines of code
of existing non trivial systems or specific solutions,
written by people who were more expert than me.
Thousands and even hundred thousands: not 5-ish.

Enough said: I won't belabour the point further.

-Julio

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

#16776

On 22/05/2025 08:51, Lawrence D'Oliveiro wrote:
> I think most of this article is a load of nonsense, myself.
> 
> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
> 
> Thoughts?

He makes some relevant points about clarity of code, but most is general 
and unrelated to booleans, and a lot of what he writes is exaggerated.

So in general, I'd prefer positive names to negative ones - 
"UserIsAuthorised" rather than "UserIsNotAuthorised".  And I would not 
"hide" a "not" in the middle of a variable name as his example does. 
But sometimes a negative name makes more sense - "UserBanned" might be 
perfectly reasonable.

All things being equal, I'd usually choose "put positive first".  But 
again, that's more a bias than a rule.  In particular, it might often be 
best with an "early exit" coming first regardless of whether it is the 
positive condition or the negative condition.

And while I agree with the principle of "no complex expressions", I 
think he is exaggerating what makes an expression complex, and picking a 
poor way to handle it.  Some parentheses can make a huge difference to 
readability without needing to introduce extra names.  Sometimes nested 
if's are a good way to split complicated conditionals.  Adding extra 
names is a good idea only if they add clarity to the code - the writer's 
examples do not.  And yes, people /will/ complain about absurdly long 
variable names.

Excessive boolean parameters in functions are bad - but so are excessive 
parameters of any other type.

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

#16777

On 22/05/2025 13:51, David Brown wrote:
> On 22/05/2025 08:51, Lawrence D'Oliveiro wrote:
>> I think most of this article is a load of nonsense, myself.
>>
>> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
>>
>> Thoughts?
> 
> He makes some relevant points about clarity of code,

He makes no relevant points: the whole thing is rather misguided.

<snip>
> So in general, I'd prefer positive names to negative ones - 
> "UserIsAuthorised" rather than "UserIsNotAuthorised".  And I would not 
> "hide" a "not" in the middle of a variable name as his example does. But 
> sometimes a negative name makes more sense - "UserBanned" might be 
> perfectly reasonable.
> 
> All things being equal, I'd usually choose "put positive first".  But 
> again, that's more a bias than a rule.  In particular, it might often be 
> best with an "early exit" coming first regardless of whether it is the 
> positive condition or the negative condition.

I could give tons of *sensible* examples where you'd have to say
"sure, maybe, in that case".  Rather, some properties and conditions
are *most naturally* expressed negatively.  Keep also in mind that
readability is way more about uniformity than the specifics, hence
some of those are/were indeed common conventions then patterns. --
More on that line in my initial post.

That said, "think positive", as the "think negative" of some of
your counter-examples, is only *dumb and dumbing*: perfectly in
line with the abolishment of negation and the dumbing down of
humanity, as negation is the fundamental logical connective...

Not that I expect *you* and the resident gang to acknowledge
any of that, of course: you cannot even engage properly.

Anyway, HTH.

-Julio

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

#16778

On 22/05/2025 14:43, Julio Di Egidio wrote:
> On 22/05/2025 13:51, David Brown wrote:
>> On 22/05/2025 08:51, Lawrence D'Oliveiro wrote:
>>> I think most of this article is a load of nonsense, myself.
>>>
>>> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
>>>
>>> Thoughts?
>>
>> He makes some relevant points about clarity of code,
> 
> He makes no relevant points: the whole thing is rather misguided.
> 
> <snip>
>> So in general, I'd prefer positive names to negative ones - 
>> "UserIsAuthorised" rather than "UserIsNotAuthorised".  And I would not 
>> "hide" a "not" in the middle of a variable name as his example does. 
>> But sometimes a negative name makes more sense - "UserBanned" might be 
>> perfectly reasonable.
>>
>> All things being equal, I'd usually choose "put positive first".  But 
>> again, that's more a bias than a rule.  In particular, it might often 
>> be best with an "early exit" coming first regardless of whether it is 
>> the positive condition or the negative condition.
> 
> I could give tons of *sensible* examples where you'd have to say
> "sure, maybe, in that case".  Rather, some properties and conditions
> are *most naturally* expressed negatively.  Keep also in mind that
> readability is way more about uniformity than the specifics, hence
> some of those are/were indeed common conventions then patterns. --
> More on that line in my initial post.
> 
> That said, "think positive", as the "think negative" of some of
> your counter-examples, is only *dumb and dumbing*: perfectly in
> line with the abolishment of negation and the dumbing down of
> humanity, as negation is the fundamental logical connective...
> 
> Not that I expect *you* and the resident gang to acknowledge
> any of that, of course: you cannot even engage properly.

Advanced exercise: do you think these are equivalent?

"I do not expect you to acknowledge any of that."
"I expect you to not acknowledge any of that."

> Anyway, HTH.

-Julio

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

#16779

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> I think most of this article is a load of nonsense, myself.
>
> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
>
> Thoughts?

It's not *all* nonsense.

> 1. Stay positive
> 2. Put positive first

Ok, sure.  UserIsAuthorized is clearer than !UserIsNotAuthorized.

> 3. No complex expressions

Meh.  The example he gives is:

    if (user.age > 18 && user.isActive && !user.isBanned && user.subscriptionLevel >= 2) {
      grantAccess();
    }

I don't find that particularly problematic.  His suggestion to replace
each subexpression with a named constant isn't horrible, and it can be
useful in some cases, but it can also add clutter.

Note that the first three points are advice about how to use Booleans
clearly, not about avoiding them.  I guess a "Foo considered harmful"
title was too tempting.

> 4. Say no to Boolean parameters

This is perhaps his most valid point.  I agree that

    saveUser(user, true, false);

is too obscure.  But for languages that support them, named parameter
associations neatly solve the problem:

    saveUser(user, sendEmail = true, verified = false);

Unfortunately, a lot of very popular languages don't have this feature.

Comments are an alternative, but not a good one; it's too easy for them
to get out of sync with the code.

> 5. Booleans are a trap for future complexity

*Anything* could be a trap for future complexity.  The example is
a Boolean "isSmallDrink", which needs to be changed when the boss
announces we're going to be serving small, medium, and large drinks.

I agree that a 2-element emum (small, large) would have been clearer
and more extensible.  But refactoring is a thing, and revisiting
an earlier decision (changing the type of a variable) is something
that has to be done all the time.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#16782

On Thu, 22 May 2025 06:51:17 -0000 (UTC), Lawrence D'Oliveiro wrote:
> I think most of this article is a load of nonsense, myself.
> 
> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
> 
> Thoughts?

I don't think he's a versatile programmer, if he expect every code to be
self explanatory at any point. He'd be stuck at specific condition(s), and
can't move on. He'll be unable to actually understand low level code such as
Assembly, even though he can learn the language.

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

#16784

On Fri, 23 May 2025 16:56:55 +0700, JJ wrote:

> I don't think he's a versatile programmer, if he expect every code to be
> self explanatory at any point.

His idea of “self-explanatory” seems to be the limiting factor. No
doubt he would throw up his hands in horror at any mention of De
Morgan’s theorems, for example.

Compare the boolean condition here:

    def colour_samples(self, to_rgb, from_rgb) :
        if (
                not isinstance(to_rgb, (list, tuple))
            or
                not isinstance(from_rgb, (list, tuple))
            or
                len(to_rgb) != len(from_rgb)
            or
                len(to_rgb) % 3 != 0
            or
                len(to_rgb) == 0
        ) :
            raise TypeError("args must be arrays of equal nonzero size, being a multiple of 3")
        #end if
        self.nr_colour_samples = len(to_rgb) // 3
        self._write_stmt("ColorSamples", [conv_num_array.conv(self._parent, to_rgb), conv_num_array.conv(self._parent, from_rgb)], {})
        return \
            self
    #end colour_samples

Would you prefer it written this way?

    def colour_samples(self, to_rgb, from_rgb) :
        if (
                isinstance(to_rgb, (list, tuple))
            and
                isinstance(from_rgb, (list, tuple))
            and
                len(to_rgb) == len(from_rgb)
            and
                len(to_rgb) % 3 == 0
            and
                len(to_rgb) != 0
        ) :
            self.nr_colour_samples = len(to_rgb) // 3
            self._write_stmt("ColorSamples", [conv_num_array.conv(self._parent, to_rgb), conv_num_array.conv(self._parent, from_rgb)], {})
        else :
            raise TypeError("args must be arrays of equal nonzero size, being a multiple of 3")
        #end if
        return \
            self
    #end colour_samples

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

#16783

On Thu, 22 May 2025 06:51:17 -0000 (UTC), I wrote:

> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>

I see the title has now changed to the less contentious “Five rules
for coding with Booleans”, and the above URL now redirects accordingly
to
<https://www.infoworld.com/article/3990923/five-rules-for-coding-with-booleans.html>.

The content hasn’t improved though.

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

#16804

On 5/22/25 2:51 AM, Lawrence D'Oliveiro wrote:
> I think most of this article is a load of nonsense, myself.
> 
> <https://www.infoworld.com/article/3990923/booleans-considered-harmful.html>
> 
> Thoughts?

   Late note - absolutely NOTHING wrong with boolean
   conditions. EASY to set up simple logic trees
   using them.

   I wonder the MOTIVES of those who say they're bad.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web