From Newsgroup: comp.programming

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

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

Thoughts?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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 */
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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
);
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.programming

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.
--- Synchronet 3.21a-Linux NewsLink 1.2