In article <uukndn$6jp4$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/3/24 03:38, David Brown wrote:
>...
>> lottery, he bought his favourite football club (or "soccer club", for
>> those who come from a country where "football" doesn't involve feet or
>> round balls)
>
>I'm curious - in which country is "football" used as the name of a sport
>that doesn't involve feet? I know of many countries where "football"
>refers to a sport where the use of hands is prohibited, and others where
>it's allowed, but I'm not aware of any where the use of feet to kick the
>ball is prohibited.

You are, of course, nitpicking. American football, as I'm sure you're
aware, is almost entirely not played with the feet.

Yes, there is kicking involved, but it is a very small part of the game and
is almost irrelevant in the grand scheme of things.

Thus ends today's lecture on sports. You may resume your normally scheduled
programming. (See, that's a little joke, because this *is* a programming
newsgroup...)

--
(Cruz certainly has an odd face) ... it looks like someone sewed pieces of a
waterlogged Reagan mask together at gunpoint ...

http://www.rollingstone.com/politics/news/how-america-made-donald-trump-unstoppable-20160224

On Wed, 03 Apr 2024 17:16:31 +0100
Richard Kettlewell <invalid@invalid.invalid> wrote:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 03/04/2024 02:23, Lawrence D'Oliveiro wrote:
>>>> It’s bloody horrible Python even when wrapped correctly. I think
>>>> Python’s version of the conditional expression is a complete
>>>> abortion.
>>>
>>> That's probably the reason almost no one uses it. That post is the
>>> first time I have ever seen conditional expressions outside of a brief
>>> mention in a tutorial on Python conditionals showing how to write
>>> normal conditionals in the language. I think Python stole this one
>>> from Perl.
>>
>> No, Perl's conditional expressions use the same syntax as C's.
>>
>> As for whether Python's conditional expression syntax, it's not clear
>> that (cond ? expr1 : expr2) is better or worse than (expr1 if cond else
>> expr2) (unless you happen to be familiar with one of them).
>
>I’ve been familiar with both for years and I think the Python version is
>awful; in particular the ordering is a bizarre choice. The PEP where
>they worked out the design acknowledges this but then they went ahead
>and did it anyway...

I believe its known as being different for the sake of being different which
is closely related to change for changes sake. Its the reason screwed up the
WIndows GUI - a new generation of devs had to prove their could be different
to the previous one regardless of how badly their new version sucked. Or in
more general cases - we've all seen new managers come in and change processes
just to prove they were doing something.

Richard Kettlewell <invalid@invalid.invalid> wrote or quoted:
>I’ve been familiar with both for years and I think the Python version is
>awful; in particular the ordering is a bizarre choice.

The way this syntax is set up is apparently credited to
this guy named Guido, according to this PEP 308 thing.

Now, in English, we usually throw a comma in there when an
"if" clause comes first, 'cause it kinda throws off the normal
flow, you know? So that shows the default position for "if"
is actually after the main part. - Maybe Guido was making that
same kind of comparison to English, and that's why he decided
the post-"if" format works better.

In my example here, there were a whole bunch of these operators
all nested inside each other without any parentheses. And let
me tell you, when you start getting into that kind of nested
stuff with not parentheses in view, even the "?:" notation
can start looking pretty darn mysterious to some folks.

On 03/04/2024 at 08:38, David Brown wrote:
> One lottery winner managed this. When he won about £160M in the
> lottery, he bought his favourite football club (or "soccer club", for
> those who come from a country where "football" doesn't involve feet or
> round balls) and set it up as a trust owned by the club's fans.

I do wish people would stop intimating that the US is the only place
where Association Football (the football we play in the UK) is known as
soccer. When I was at secondary school (back in the 1960's) "soccer
practise" was a well know alternative to the term "football practise".

--
Chris Elvidge, England
I WILL NOT BE A SNICKERPUSS.

On Thu, 4 Apr 2024 14:50:19 +0100
Chris Elvidge <chris@mshome.net> wrote:
>On 03/04/2024 at 08:38, David Brown wrote:
>> One lottery winner managed this. When he won about £160M in the
>> lottery, he bought his favourite football club (or "soccer club", for
>> those who come from a country where "football" doesn't involve feet or
>> round balls) and set it up as a trust owned by the club's fans.
>
>I do wish people would stop intimating that the US is the only place
>where Association Football (the football we play in the UK) is known as
>soccer. When I was at secondary school (back in the 1960's) "soccer
>practise" was a well know alternative to the term "football practise".

IME the only people in the UK who call football "soccer" are rugger bugger
types.

On 04/04/2024 15:50, Chris Elvidge wrote:
> On 03/04/2024 at 08:38, David Brown wrote:
>> One lottery winner managed this.  When he won about £160M in the
>> lottery, he bought his favourite football club (or "soccer club", for
>> those who come from a country where "football" doesn't involve feet or
>> round balls) and set it up as a trust owned by the club's fans.
>
> I do wish people would stop intimating that the US is the only place
> where Association Football (the football we play in the UK) is known as
> soccer. When I was at secondary school (back in the 1960's) "soccer
> practise" was a well know alternative to the term "football practise".
>

The term "soccer" is sometimes used in the UK, yes. It is most common
in schools or areas of the country where rugby (also occasionally known
as "Rugby Football") is popular.

But the term "football", unqualified, invariably means "soccer" - except
in the USA.

On 2024-04-04, Chris Elvidge <chris@mshome.net> wrote:
> On 03/04/2024 at 08:38, David Brown wrote:
>> One lottery winner managed this. When he won about £160M in the
>> lottery, he bought his favourite football club (or "soccer club", for
>> those who come from a country where "football" doesn't involve feet or
>> round balls) and set it up as a trust owned by the club's fans.
>
> I do wish people would stop intimating that the US is the only place
> where Association Football (the football we play in the UK) is known as
> soccer. When I was at secondary school (back in the 1960's) "soccer
> practise" was a well know alternative to the term "football practise".
>

+1

On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:

> And let me tell you, when you start getting into that kind of nested
> stuff with not parentheses in view, even the "?:" notation can start
> looking pretty darn mysterious to some folks.

This is where indentation helps. E.g.

a =
b ?
c ? d : e
: f ?
g ? h : i
: j;

On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>
>> And let me tell you, when you start getting into that kind of nested
>> stuff with not parentheses in view, even the "?:" notation can start
>> looking pretty darn mysterious to some folks.
>
>This is where indentation helps. E.g.
>
> a =
> b ?
> c ? d : e
> : f ?
> g ? h : i
> : j;

Just use brackets. Saves a lot of pain.

Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday (GMT):
> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>
>>> And let me tell you, when you start getting into that kind of nested
>>> stuff with not parentheses in view, even the "?:" notation can start
>>> looking pretty darn mysterious to some folks.
>>
>>This is where indentation helps. E.g.
>>
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

Or just use if blocks if it's too complex.
--
user <candycane> is generated from /dev/urandom

On Fri, 5 Apr 2024 12:40:02 -0000 (UTC)
candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
>Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday
>(GMT):
>> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>>
>>>> And let me tell you, when you start getting into that kind of nested
>>>> stuff with not parentheses in view, even the "?:" notation can start
>>>> looking pretty darn mysterious to some folks.
>>>
>>>This is where indentation helps. E.g.
>>>
>>> a =
>>> b ?
>>> c ? d : e
>>> : f ?
>>> g ? h : i
>>> : j;
>>
>> Just use brackets. Saves a lot of pain.
>
>
>Or just use if blocks if it's too complex.

Indeed. It might not look as "l33t", but with modern compilers it'll end
up as the same assembler anyway.

On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
> On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>
>> And let me tell you, when you start getting into that kind of nested
>> stuff with not parentheses in view, even the "?:" notation can start
>> looking pretty darn mysterious to some folks.
>
> This is where indentation helps. E.g.
>
> a =
> b ?
> c ? d : e
> : f ?
> g ? h : i
> : j;
>

Indentation generally helps. In above code (in my book) it's not
that clear [from the indentation], e.g. where the last ':' 'else'
belongs to. So I'd have lined the colons up with the respective
'?'. (YMMV.)

Not all languages differentiate (per syntax) a conditional command
from a conditional expression. Here are the two forms supported by
Algol for both, statements and expressions (here the examples are
both depicted for expressions only)

a :=
( b | ( c | d | e )
| ( f | ( g | h | i )
| j ) );

The parenthesis are not used for grouping, but are the alternative
form for IF/THEN/ELSE/FI

a := IF b
THEN
IF c THEN d ELSE e FI
ELSE
IF f THEN
IF g THEN h ELSE i FI
ELSE j FI
FI

Pick your choice depending on the case (or taste).

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:
>On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
>>This is where indentation helps. E.g.
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>>
>Indentation generally helps.

Let me give it a try to find how I would indent that!

b?
c? d: e:
f?
g? h: i:
j;

>The parenthesis are not used for grouping, but are the alternative
>form for IF/THEN/ELSE/FI

It's funny how the discussion oscillates between
"too many parentheses" (LISP code) and "not enough parentheses"
("let me add some parens to improve readability").

On 2024-04-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
>> On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>
>>> And let me tell you, when you start getting into that kind of nested
>>> stuff with not parentheses in view, even the "?:" notation can start
>>> looking pretty darn mysterious to some folks.
>>
>> This is where indentation helps. E.g.
>>
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>>
>
> Indentation generally helps. In above code (in my book) it's not
> that clear [from the indentation], e.g. where the last ':' 'else'
> belongs to. So I'd have lined the colons up with the respective
> '?'. (YMMV.)
>
> Not all languages differentiate (per syntax) a conditional command
> from a conditional expression. Here are the two forms supported by
> Algol for both, statements and expressions (here the examples are
> both depicted for expressions only)
>
> a :=
> ( b | ( c | d | e )
> | ( f | ( g | h | i )
> | j ) );
>
> The parenthesis are not used for grouping, but are the alternative
> form for IF/THEN/ELSE/FI
>
> a := IF b
> THEN
> IF c THEN d ELSE e FI
> ELSE
> IF f THEN
> IF g THEN h ELSE i FI
> ELSE j FI
> FI
>
> Pick your choice depending on the case (or taste).

#define XCAT(A, B) A ## B
#define CAT(A, B) XCAT(A, B)

#define IF(A, B, C) ((A) ? (B) : (C))

#define COND_2(cond, then, ...) IF(cond, then, 0)
#define COND_4(cond, then, ...) IF(cond, then, COND_2(__VA_ARGS__))
#define COND_6(cond, then, ...) IF(cond, then, COND_4(__VA_ARGS__))
#define COND_8(cond, then, ...) IF(cond, then, COND_6(__VA_ARGS__))

#define COND_1(...) {syntax error}
#define COND_3(...) {syntax error}
#define COND_5(...) {syntax error}
#define COND_7(...) {syntax error}

#define COUNT_ARGS(...) COUNT_ARGS_IMPL(__VA_ARGS__, 8, 7, 6, 5, 4, 3, 2, 1)
#define COUNT_ARGS_IMPL(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N

#define COND(...) CAT(COND_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)

Now we can do:

COND(b, ...,
f, ...
1, j)

filling in the ...:

COND(b, IF(c, d, e),
f, IF(g, h, i),
1, j)

The GNU preprocessor gives me this:

((b) ? (((c) ? (d) : (e))) : (((f) ? (((g) ? (h) : (i))) : (((1) ? (j) : (0))))))

which looks correct.

The code is readable now, and importantly, my editor can format it. If I
start adding line breaks, it's indented right. If I turn it into this:

COND(b, IF(c, d, e),
f, IF(g, h, i),
1, j)

then highlight it in Vim and hit =, it gets put back the way it was.

If I add line breaks into the IFs, they get automatically indented
right, just using Vim's support for basic C formatting of macro/function
calls:

cond(b, IF(c,
d,
e),
f, IF(g,
h,
i),
1, j)

Compared to wrestling with five ways of formatting the the ill-conceived
?: syntax, it's a complete no brainer.

Here is a version where the cond pairs have to be parenthesized.
We can lose the even/odd argument count handling, and might as well
extend to up to 8 clauses:

#define IF(A, B, C) ((A) ? (B) : (C))

#define XCAT(A, B) A ## B
#define CAT(A, B) XCAT(A, B)

#define COND_PAIR(pair, rest) IF(COND_COND pair, COND_THEN pair, rest)
#define COND_COND(cond, then) cond
#define COND_THEN(cond, then) then
#define COND_1(pair, ...) COND_PAIR(pair, 0)
#define COND_2(pair, ...) COND_PAIR(pair, COND_1(__VA_ARGS__))
#define COND_3(pair, ...) COND_PAIR(pair, COND_2(__VA_ARGS__))
#define COND_4(pair, ...) COND_PAIR(pair, COND_3(__VA_ARGS__))
#define COND_5(pair, ...) COND_PAIR(pair, COND_4(__VA_ARGS__))
#define COND_6(pair, ...) COND_PAIR(pair, COND_5(__VA_ARGS__))
#define COND_7(pair, ...) COND_PAIR(pair, COND_6(__VA_ARGS__))
#define COND_8(pair, ...) COND_PAIR(pair, COND_7(__VA_ARGS__))

#define COUNT_ARGS(...) COUNT_ARGS_IMPL(__VA_ARGS__, 8, 7, 6, 5, 4, 3, 2, 1)
#define COUNT_ARGS_IMPL(_1, _2, _3, _4, _5, _6, _7, _8, N, ...) N

#define COND(...) CAT(COND_, COUNT_ARGS(__VA_ARGS__))(__VA_ARGS__)

COND((b, IF(c,
d,
d)),
(f, IF(g,
h,
i)),
(1, j))

The expansion is still

((b) ? (((c) ? (d) : (d))) : (((f) ? (((g) ? (h) : (i))) : (((1) ? (j) : (0))))))

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 5 Apr 2024 18:30:12 +0200, Janis Papanagnou wrote:

> Here are the two forms supported by Algol ...

Just a note, that’s Algol 68. In my time, “Algol” used unqualified was
understood to refer to Algol 60.

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:

> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC) Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
>>
>>This is where indentation helps. E.g.
>>
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

The improvement speaks for itself.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
...
>> a =
>> b ?
>> c ? d : e
>> : f ?
>> g ? h : i
>> : j;
>
> Just use brackets. Saves a lot of pain.

a=(b?(c?d:e):(f?(g?h:i):j));

A normal programmer would write something like:

a = b ? (c ? d : e) :
f ? (g ? h : i) :
j;

I.e., she would allow herself to use spaces and newlines, and just
enough parentheses to make the structure clear.

- Alan

On Fri, 05 Apr 2024 19:35:37 -0400, Alan Bawden wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
> A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
> I.e., she would allow herself to use spaces and newlines, and just
> enough parentheses to make the structure clear.

It’s like, I don’t know ... you’re trying to save space. Why?

It’s like programming inside an apartment block, instead of having a
bungalow with a yard of your own.

On 2024-04-05, Alan Bawden <alan@csail.mit.edu> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
> A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
> I.e., she would allow herself to use spaces and newlines, and just
> enough parentheses to make the structure clear.

It looks good, undeniably.

However, I cannot tell at a glance whether or not the nice appearance
isn't telling me some kind of lie. That's an inherent problem with
the ternary operator.

I have to remember that = has lower precedence than ?:. But, ==
has higher precedence. So this careless edit makes it wrong,
even though it still looks just as nice:

a == b ? (c ? d : e) :
f ? (g ? h : i) :
j;

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 15:09 this Friday (GMT):
> On Fri, 5 Apr 2024 12:40:02 -0000 (UTC)
> candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> wrote:
>>Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote at 09:17 this Friday
>>(GMT):
>>> On Thu, 4 Apr 2024 23:29:21 -0000 (UTC)
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>On 4 Apr 2024 11:20:48 GMT, Stefan Ram wrote:
>>>>
>>>>> And let me tell you, when you start getting into that kind of nested
>>>>> stuff with not parentheses in view, even the "?:" notation can start
>>>>> looking pretty darn mysterious to some folks.
>>>>
>>>>This is where indentation helps. E.g.
>>>>
>>>> a =
>>>> b ?
>>>> c ? d : e
>>>> : f ?
>>>> g ? h : i
>>>> : j;
>>>
>>> Just use brackets. Saves a lot of pain.
>>
>>
>>Or just use if blocks if it's too complex.
>
> Indeed. It might not look as "l33t", but with modern compilers it'll end
> up as the same assembler anyway.

Yeah. Not everything needs to be a hyper optimized single line
statement.
--
user <candycane> is generated from /dev/urandom

Alan Bawden <alan@csail.mit.edu> wrote at 23:35 this Friday (GMT):
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
> A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
v (she?)
> I.e., she would allow herself to use spaces and newlines, and just
> enough parentheses to make the structure clear.
>
> - Alan

Yeah, a bit of space for the code to breathe goes a long way.
--
user <candycane> is generated from /dev/urandom

On 5 Apr 2024 17:37:52 GMT
ram@zedat.fu-berlin.de (Stefan Ram) wrote:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote or quoted:
>>On 05.04.2024 01:29, Lawrence D'Oliveiro wrote:
>>>This is where indentation helps. E.g.
>>> a =
>>> b ?
>>> c ? d : e
>>> : f ?
>>> g ? h : i
>>> : j;
>>>
>>Indentation generally helps.
>
> Let me give it a try to find how I would indent that!
>
>b?
> c? d: e:
> f?
> g? h: i:
> j;
>
>>The parenthesis are not used for grouping, but are the alternative
>>form for IF/THEN/ELSE/FI
>
> It's funny how the discussion oscillates between
> "too many parentheses" (LISP code) and "not enough parentheses"
> ("let me add some parens to improve readability").

Lisp overloads them as block markers which simply makes the code more
confusing, not less.

On Fri, 05 Apr 2024 19:35:37 -0400
Alan Bawden <alan@csail.mit.edu> wrote:
>Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
> ...
> >> a =
> >> b ?
> >> c ? d : e
> >> : f ?
> >> g ? h : i
> >> : j;
> >
> > Just use brackets. Saves a lot of pain.
>
> a=(b?(c?d:e):(f?(g?h:i):j));
>
>A normal programmer would write something like:
>
> a = b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>
>I.e., she would allow herself to use spaces and newlines, and just

ITYM "he" would allow HIMself.

Lets give the woke BS a miss, 95% of developers are men. It doesn't give you
any brownie points, just makes you look a try-hard ass.

On 06/04/2024 03:01, Kaz Kylheku wrote:
> On 2024-04-05, Alan Bawden <alan@csail.mit.edu> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> On Fri, 5 Apr 2024 09:17:37 -0000 (UTC), Muttley wrote:
>> ...
>> >> a =
>> >> b ?
>> >> c ? d : e
>> >> : f ?
>> >> g ? h : i
>> >> : j;
>> >
>> > Just use brackets. Saves a lot of pain.
>>
>> a=(b?(c?d:e):(f?(g?h:i):j));
>>
>> A normal programmer would write something like:
>>
>> a = b ? (c ? d : e) :
>> f ? (g ? h : i) :
>> j;
>>
>> I.e., she would allow herself to use spaces and newlines, and just
>> enough parentheses to make the structure clear.
>
> It looks good, undeniably.
>
> However, I cannot tell at a glance whether or not the nice appearance
> isn't telling me some kind of lie. That's an inherent problem with
> the ternary operator.

That's a key point - and it is not just with the ternary operator, but a
general issue. Good spacing, indentation, newlines and layout make code
easier to read. But it is vital that there is never any doubt that the
layout matches the meaning of the code. If not, then you might be sure
what the programmer meant dues to the layout, but you are not sure that
the compiler sees it the same way. After all, this looks neat and clear
too :

a =
b & c +
d & e +
f & g

But the language viewpoint (assuming it is in C, or a language with
similar precedences) and the code appearance are very different.

Parentheses help, until there are too many to be easily tracked by the
reader. Splitting the expression into parts, adding new local
variables, using separate statements, making new helper functions -
these are all ways to improve the code, and have no efficiency cost with
modern tools.

A lot of people think the layout of code should make the programmer's
intentions clear, and make it easy to see what the code does. That's
true, but it is not enough. Code layout should also make it easy to see
that the code does what the programmer intended. It should be easy for
a maintainer to modify it without introducing errors. It should also be
hard for a reader to misinterpret it (which is not the same as saying it
should be easy to interpret correctly). It should be hard for a
maintainer to make mistakes. It should be easy to spot any mistakes
that get made.

>
> I have to remember that = has lower precedence than ?:. But, ==
> has higher precedence. So this careless edit makes it wrong,
> even though it still looks just as nice:
>
> a == b ? (c ? d : e) :
> f ? (g ? h : i) :
> j;
>

On Sat, 6 Apr 2024 15:44:13 +0200
David Brown <david.brown@hesbynett.no> wrote:
>A lot of people think the layout of code should make the programmer's
>intentions clear, and make it easy to see what the code does. That's

Unfortunately IME another lot (usually young) seem to think that the more
complicated their make their code the more it will impress their peers and/or
boss. This seems to be a particular problem with C++ as its current overspecced
and overcomplicated syntax allows you to write code that would make a Perl dev
envious.