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

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

Thoughts?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)