In article <yGCQM.35598$ugs.11802@fx36.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>In article <20230926171422.fbc681174edadb9d385a9c0f@gmail.moc>,
>>Anton Shepelev <anton.txt@gmail.moc> wrote:
>>>Dan Cross:
>>>
>>>> Robert C Martin is, at best, a middling-quality
>>>> programmer.
>>>
>>>Maybe he is, but how do you come to that conclusion?
>>
>>By examining his publicly available work, as well as his
>>writing.
>>
>>"Clean Code" in particular is rife with spelling and grammar
>>errors, and one can look at his code on Github. See, for
>>example, this:
>>https://github.com/unclebob/PDP8EmulatorIpad/pull/2
>>(Here's the original source program:
>>https://github.com/unclebob/PDP8EmulatorIpad/blob/1eba53c08fb530effb9d29aca8134f7acadfdd5f/src/topt.c
>
>What's with the screwy indentation? That's a 'do not hire this guy' flag.
>
>Waste of time to bzero the string before constructing it using strcpy,
>rather than just using snprintf().
>
>Ah, I see your point is that he writes poor code.

Indeed! Strangely kind par for the course on people who have
strongly held opinions on programming.

- Dan C.

On 26/09/2023 17:40, Kaz Kylheku wrote:
> On 2023-09-26, Bart <bc@freeuk.com> wrote:
>> On 26/09/2023 16:10, David Brown wrote:

>> What is the actual rule about braces? Because you've clearly missed some
>> out there, in omitting them around the first two 'else' branches.
>
> The actual rules is that the required braces, comprising a compound
> statement, can be prefixed by something which modifies the statement
> into a conditional.

But then that compound statement becomes a single statement with no
braces of its own, and many of the problems associated with optional
braces return.

>> If you saying this is OK, then that's playing fast and rule with any
>> such rule that braces must always be used even around one statement.
>
> Indeed, I myself sometimes writes in a style like the following:
>
> if (condition) {
> /* loop not needed */
> } else for (...) {
>
> }
>
> The else keyword needs a statement, and the for statement
> satisfies it. It has braces of its own, so everything is cool.

Suppose you were to write it like this:

} else
for (...) {

then someone adds an extra statement:

} else
puts("Loop follows.");
for (...) {

Now it's not so cool.

Really, it's quite silly: how far deep inside a series of /single/
nested statements are you allowed to go, to enable you to claim that
your 'else' branch is actually brace-delimited?

> What I wouldn't write is:
>
>
> if (condition) {
> /* loop not needed */
> } else

Why wouldn't you write this? Presumably something might be added there
in future, otherwise it's a poorly thought-out condition.

> Some languages combine "else" and "if" into a single token, even.
> The C preprocessing language is like that: #elif.

This has always puzzled me, where C's preprocessor has a more grown-up,
more solid , more readable and less error prone syntax than the main
language. No dangling 'else' there!

David Brown to Anton Shepelev:

> > Modern languages with multiple returns or tuples provide
> > a partial solution, another being to unify error info
> > with the result of successful execution in dynamic
> > languages or ones with templates (to save the declaring
> > a combined TResult type for every function). But then,
> > I loose the whole pupose of an error flag -- the ability
> > to invoke funtions inside an `if' statement.
>
> You realise that in C you can return structs, and thus
> include status returns as well as value returns in one
> item?

I do, which is why I wrote about defining a
<func_name>TResult type for /every/ function. If, on the
other hand, I define TResult to contain only error
information and the success flag, I save a single parameter
compared to returning the success flag and error info
separately.

> Still, why are you talking about modern languages and
> object oriented programming when you insist on using a
> language outdated a generation ago?

Because C lacks those new features and I am spared the
pressure to use them in my code :-) Seriously, I see nothing
bad in considering alternative approaches to get out of the
box, so to say... I do not think C is outdated a generation
ago, and even the new standards have far from changed it
beyond recognition. It is basically the same language.

> > Linus 8-chareater-tab Torvalds was IMHO right when he
> > decreed that a function shall not have more then three
> > levels of nesting, his enourmous tab serving as a dumb,
> > primitive, mechanical, and ugly means of enforsing this
> > decree.
>
> No, Linus was wrong - as he is on many things. (He's
> right on many things too, of course.) We are not using
> typewriters, we are not using 80x25 character displays,
> and we do not need to have pointless limitations.

They are not pointless. 80 characters is a generous the
upper limit of a compfortable line width, most typographical
manuals suggesting lower lengths, and I did not refer to the
25-line limit anywhere. My functions are frequently longer.

> I don't advocate for deeply nested or overly complex
> functions, of course - I advocate for clear code with
> immediately obvious blocks indicated by braces /and/
> indents. And if clear code requires more than 3 levels of
> nesting, use that.

In my opinion, up to three levels are easy to perceive, and
then it becomes harder epxonentially: four levels is
tolerable and five is a mess.

> > For an example, and the standard if-else-if-else...
> > chain is in fact a variant of a switch, and a switch has
> > the
>
> Not in C.

Yes, I meant the broader condept of switch as a table of
tests and corresponding statements, with perhaps a fallback
(default) entry. The point is that the sturcture of switch
is a table with two columns (see below).

> > if( test_1 ) {
> > stat_1 } else {
> > if( test_2 ) {
> > stat_2 } else {
> > if( test_3 ) {
> > stat_3 } else {
>
> I have never seen if-else chains formatted that way - it
> is clearly incorrect indentation.

It is technically /the one true/ correct indentation,
because each level of nesting has its own indent.

> if (test1) {
> stat_1;
> } else if (test2) {
> stat_2;
> } else if (test3) {
> stat_3;
> } else {
> ...
> }

Now, you have recoginised that although syntatically it is a
deeply nested unblananced tree, semantically it is a linear
structure, and therefore you flattened it, so that the
nesting level is no longer equal to the indent. Does a dumb
pretty-printer understand semantics? Do coding standards
care about semantics?

> > if( test_1 ) stat_1;
> > else if( test_2 ) stat_2;
> > else if( test_3 ) stat_3;
> >
> > It shorter, clearer, and better structured, because the
> > programmer has formatted the code according its intent.
> > Observe also the indent of the first `if' to have it
> > aligned with the other entries of the table.
>
> That's a strawman argument, because no one would ever
> write an if-else chain the way you first suggested.

No, what /you/ say after `because' is a strawman argument
becase it appeals to external circumstances (the number of
followers) rather than criticises the formatting itself. I
will try to explain my formatting again: the structure of
that control statement is a table with two columns and three
rows. A careful programmer, having respect for the reader,
will therefore take advantage of the 2-dimensional nature of
text and format it in a 2x3 grid, aligning the correspondent
parts together:
test_1 stat_1
test_2 stat_2
test_3 stat_3

It is only meet also to alignt the correspondent keywords,
as I have done above. This is the only way to express the
programmer's intent in the formatting. Curly braces would
be redundant, because the structure is sufficiently
transparent not to require them, but you can add them
anyway:
if( test_1 ) { stat_1 ; }
else if( test_02 ) { stat_02 ; }
else if( test_003 ) { stat_003; }

I have introduced indentifiers of varying length to show the
correct horisontal alignment of closing parentheses, curly
braces, and semicolons.

You say that your version above

> is clearer than yours, and far more maintainable.

I outright deny that it is any clearer. It is certainly
messier and less structured, which any non-programmer, or a
programmer without professional bias due to experience with
curly languages, should confirm. Show them our styles
side-by-side:

Format I | Format II
|
if (test1) { | if( test_1 ) stat_1 ;
stat_1; | else if( test_2 ) stat_2 ;
} else if (test2) { | else if( test_3 ) stat_3 ;
stat_2; | else stat_def;
} else if (test3) { |
stat_3; |
} else { |
stat_def; |
} |

As to maintainability, it depends. My version is suitable
for small, ideally single, statements, whereas yours is more
universal and works better with large, compund ones. In my
own practice, however, I never need an if-else chain with
large statements, for some reason. If I should suddently
need to introduce long statements into my if-else chain, I
will then rewrited it differently, but not before. The
problem of universal one-for-all formatting rules is that
they are not optimised to the situation at hand, cf. my
three versions of an shortened if-else statement, each for
its own purpose.

> And any coding standard with a care for safety, security
> or reliability, (such as MISRA or JSF-AV mentioned in this
> thread) will insist on the braces here.

Why is my version unsafe, insecure, and unreliable? What
kind of error does it invite? My opinion is that, as long
as the grahica tabular alignment is kept in place, human
errors are very unlikely.

> > Coding standards rarery (if ever) take these semantical
> > (intent) and perceptinve (table) considerations into
> > accout, whereas automatic linters or pretty-printers
> > supply the necessary technology to implement this
> > Nazism.
>
> I have no idea what you are trying to say there.

That quotation contain two parts. The first one states that
coding standards require a uniform formatting style based on
the syntax of the language, ignoring the fact that the same
syntax may express different semantics. For example, a
syntatically deeply nested if-else statement may be written
with deep indentaiton and without (as you have done above),
depending on the intent of the programmer it expresses, that
is whether it is sematically deeply nested. The enforcement
of a uniform formatting regardless of intent makes code less
readable.

The second part refers to my previous observation that
coding standards are often enforced by automatic tools,
which (unaware of sematics and the programmer's intent),
format everything accroding to the same mechanical (syntax-
based) rules, effectively destroying any effort of the
programmer to increase readability by emphasizing code
structure via semantic formatting.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 26/09/2023 18:53, Anton Shepelev wrote:
> David Brown to Anton Shepelev:

>> if (test1) {
>> stat_1;
>> } else if (test2) {
>> stat_2;
>> } else if (test3) {
>> stat_3;
>> } else {
>> ...
>> }
>
> Now, you have recoginised that although syntatically it is a
> deeply nested unblananced tree, semantically it is a linear
> structure, and therefore you flattened it, so that the
> nesting level is no longer equal to the indent. Does a dumb
> pretty-printer understand semantics? Do coding standards
> care about semantics?

If I take that example, with an extra branch:

if (test1) {
stat_1;
} else if (test2) {
stat_2;
} else if (test3) {
stat_3;
} else if (test4) {
stat_4;
} else {
stat_5;
}

and pass it through a visualisation tool that turns it into my syntax, I
get this:

if test1 then
stat_1
else
if test2 then
stat_2
else
if test3 then
stat_3
else
if test4 then
stat_4
else
stat_5
fi
fi
fi
fi

The indent level expands sideways as the length of the chain increases.
(Actully I can see the same thing when looking at the generated AST.)

I need a way to detect whether an if-else-if chain was intended, because
that is not the natural form of such a sequence in C. If successul, that
output would instead be:

if test1 then
stat_1
elsif test2 then
stat_2
elsif test3 then
stat_3
elsif test4 then
stat_4
else
stat_5
fi

But I'm not sure that can be done in foolproof manner. Maybe the intent
of the original C /was/ a nested structure with increasing indents.

On 9/26/2023 12:22 AM, Chris M. Thomasson wrote:
> On 9/25/2023 11:55 PM, David Brown wrote:
>> On 25/09/2023 21:42, Chris M. Thomasson wrote:
>>>
>>> I must of remembered it wrong David. I think I remember something
>>> about trying not to have too many functions in a class...
>>
>> That is not in MISRA either, nor in the JSF rules you linked.  (The
>> JSF rules take a lot of inspiration from MISRA, and are IMHO a better
>> set of rules.)
>>
>> I don't know of any coding standards that have fixed maximum limits to
>> the size of functions or the number of functions in a file.  That
>> makes sense, since there is no way to pick an absolute limit - it
>> varies too much by circumstance.  The best you can have is a
>> generalisation, not a rule - do not make your source files so big or
>> have so many functions that they are difficult to navigate.
>>
>>
>
> Yeah. I was misremembering section 3.2:
> ________________________________
> 3.2 Code Size and Complexity
> AV Rule 1
> Any one function (or method) will contain no more than 200 logical
> source lines of code (LSLOCs).
> Rationale: Long functions tend to be complex and therefore difficult to
> comprehend and test.

For some reason the rationale reminded me of you and Kaz wrt being a
good programmer. :^)

> Note: Section 4.2.1 defines should and shall rules as well the
> conditions under which
> deviations from should or shall rules are allowed.
> AV Rule 2
> There shall not be any self-modifying code.
> Rationale: Self-modifying code is error-prone as well as difficult to
> read, test, and maintain.
> AV Rule 3
> All functions shall have a cyclomatic complexity number of 20 or less.
> Rationale: Limit function complexity. See AV Rule 3 in Appendix A for
> additional details.
> Exception: A function containing a switch statement with many case
> labels may exceed this
> limit.
> Note: Section 4.2.1 defines should and shall rules as well the
> conditions under which
> deviations from should or shall rules are allowed.
> ________________________________
>
> And appendix A wrt AV rule 3.

On 2023-09-26, Bart <bc@freeuk.com> wrote:
> and pass it through a visualisation tool that turns it into my syntax, I
> get this:
>
> if test1 then
> stat_1
> else
> if test2 then
> stat_2
> else
> if test3 then
> stat_3
> else
> if test4 then
> stat_4
> else
> stat_5
> fi
> fi
> fi
> fi
>
> The indent level expands sideways as the length of the chain increases.
> (Actully I can see the same thing when looking at the generated AST.)

In Lisp there is no such conundrum.

(if test-1
stat-1
(if test2
stat-2
(if test3
stat-3
(if test4
stat-4
stat-5))))

There is no ladder coding style to make this vertical; any attempt to
make one would be repugnant, due to incorrect indentation:

(if test-1
stat-1
(if test2
stat-2
(if test3
stat-3
(if test4
stat-4
stat-5))))

You'd be constantly fighting with the editor which would be indenting
it.

How you make it vertical is via cond

(cond
(test-1 stat-1)
(test-2 stat-2)
(test-3 stat-3)
(test-4 stat-4)
(t stat-5))

Note that cond came before if. It allowed (cond (x y) (t z)) to be
condensed to (if x y z). Originally, cond clauses were strictly
pairs called "cond pairs". In ANSI Common Lisp they can have one
or more clauses. If the first expression is true, the remaining
expresssions, if any, are evaluated. The value of the last expression
in the clause becomes the result; thus (cond (3)) yields 3.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 27/09/2023 00:05, Kaz Kylheku wrote:
> On 2023-09-26, Bart <bc@freeuk.com> wrote:
>> and pass it through a visualisation tool that turns it into my syntax, I
>> get this:
>>
>> if test1 then
>> stat_1
>> else
>> if test2 then
>> stat_2
>> else
>> if test3 then
>> stat_3
>> else
>> if test4 then
>> stat_4
>> else
>> stat_5
>> fi
>> fi
>> fi
>> fi
>>
>> The indent level expands sideways as the length of the chain increases.
>> (Actully I can see the same thing when looking at the generated AST.)
>
> In Lisp there is no such conundrum.
>
> (if test-1
> stat-1
> (if test2
> stat-2
> (if test3
> stat-3
> (if test4
> stat-4
> stat-5))))
>
> There is no ladder coding style to make this vertical; any attempt to
> make one would be repugnant, due to incorrect indentation:
>
> (if test-1
> stat-1
> (if test2
> stat-2
> (if test3
> stat-3
> (if test4
> stat-4
> stat-5))))
>
> You'd be constantly fighting with the editor which would be indenting
> it.
>
> How you make it vertical is via cond
>
> (cond
> (test-1 stat-1)
> (test-2 stat-2)
> (test-3 stat-3)
> (test-4 stat-4)
> (t stat-5))

Yes this looks like the 'case-when' statement I posted a day or two ago.
If I rename 'case' to 'cond', and 'else' to 't', then it's almost the
same other than the style of syntax.

But this is yet another solution that doesn't exist in the main C language.

I wonder how big a deal it would have been to introduce an actual
'else-if' token? I expect it would look something like _Elseif; just
using a the hypenated 'else-if' would be better!

Bart <bc@freeuk.com> writes:
[...]
> I wonder how big a deal it would have been to introduce an actual
> 'else-if' token? I expect it would look something like _Elseif; just
> using a the hypenated 'else-if' would be better!

A hyphenated keyword?

In various languages, I've seen "elif", "elsif", and "elseif".
I'd be fine with any of those.

But though I think it would have been nice to add such a keyword from
the beginning, I'm not convinced it would be worth doing now. It's
already perfectly possible to write long if/else chains in C:

if (...) {
...
}
else if (...) {
...
}
else if (...) {
...
}
else {
...
}

(I know some people prefer to put the else on the same line as the {.
That's not really the point.)

Even though the indentation doesn't strictly reflect the grammar, it's a
common enough idiom that that doesn't bother me.

Adding it as _Elseif would IMHO be too ugly. Adding a new keyword
always risks breaking existing code, but C23 is already adding bool,
false, and true.

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

On 2023-09-27, Bart <bc@freeuk.com> wrote:
> On 27/09/2023 00:05, Kaz Kylheku wrote:
>> How you make it vertical is via cond
>>
>> (cond
>> (test-1 stat-1)
>> (test-2 stat-2)
>> (test-3 stat-3)
>> (test-4 stat-4)
>> (t stat-5))
>
>
> Yes this looks like the 'case-when' statement I posted a day or two ago.
> If I rename 'case' to 'cond', and 'else' to 't', then it's almost the
> same other than the style of syntax.
>
> But this is yet another solution that doesn't exist in the main C language.

Yes; the multi-conditional statement is simulated by nested ifs.

> I wonder how big a deal it would have been to introduce an actual
> 'else-if' token? I expect it would look something like _Elseif; just
> using a the hypenated 'else-if' would be better!

You can get something like it using the preprocessor:

#define elif else if

The paradigm of "elif" is less flexible; since the lone else
combines with statements other than if as I showed in other posts:

if (this) {
x = 42;
} else while (i--) {
foo(j++);
}

A C implementation is free to recognize the abstract syntax tree
pattern:

if (E1) S1
else if (E2) S2
...
else if (EN) SN
else SF

and rewrite it into a single abstract tree node implementing
an equivalent internal case statement. That form could facilitate
certain analyses, like turning case into a switch, because that AST node
would have the clauses as children at the same level. E.g. answering
the question whether all the Ei expressions are constant would be a
simple iteration.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

On 2023-09-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Adding it as _Elseif would IMHO be too ugly. Adding a new keyword
> always risks breaking existing code, but C23 is already adding bool,
> false, and true.

One advantage might be that in LALR(1) parsing, "_Elseif" is a
single symbol, consuming only one lookahead position, whereas "else if"
is two tokens. If we are at else, and the next token is if, that's our
lookeahead; we don't see past it. Whereas if wee are at _Elseif,
we have whatever token follows as lookahead.

I can't think of what situations that would benefit; i.e. what could
be parsed that is not parseable now.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-09-27, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> Adding it as _Elseif would IMHO be too ugly. Adding a new keyword
>> always risks breaking existing code, but C23 is already adding bool,
>> false, and true.
>
> One advantage might be that in LALR(1) parsing, "_Elseif" is a
> single symbol, consuming only one lookahead position, whereas "else if"
> is two tokens. If we are at else, and the next token is if, that's our
> lookeahead; we don't see past it. Whereas if wee are at _Elseif,
> we have whatever token follows as lookahead.
>
> I can't think of what situations that would benefit; i.e. what could
> be parsed that is not parseable now.

Nor can I -- and if I could, I'd probably try to avoid writing code like
that.

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

On 26/09/2023 17:29, Malcolm McLean wrote:
> On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote:
>> On 26/09/2023 13:37, Anton Shepelev wrote:
>>>
>>> Linus 8-chareater-tab Torvalds was IMHO right when he
>>> decreed that a function shall not have more then three
>>> levels of nesting, his enourmous tab serving as a dumb,
>>> primitive, mechanical, and ugly means of enforsing this
>>> decree.
>> No, Linus was wrong - as he is on many things. (He's right on many
>> things too, of course.) We are not using typewriters, we are not using
>> 80x25 character displays, and we do not need to have pointless
>> limitations. I don't advocate for deeply nested or overly complex
>> functions, of course - I advocate for clear code with immediately
>> obvious blocks indicated by braces /and/ indents. And if clear code
>> requires more than 3 levels of nesting, use that.
>>
> Rule of three. Three levels of nesting or indirection. Because we live in a three
> dimensional world.

Rule of seven. Seven levels of nesting or indirection. Because we have
seven days in the week.

See? Anyone can write complete and utter drivel, with totally
nonsensical "justifications".

Don't you ever get tired of spouting these insane platitudes, as though
you imagine yourself as some kind of holy prophet of programming? Your
track record here, and the way you make such pronouncements as if you
were revealing the hidden laws of the universe, makes people assume you
are wrong. Even though you are sometimes accidentally correct, or at
least partially right, the gut reaction is that Malcolm is pontificating
again, so its nonsense.

Please put a post-it note on the top of your screen - "There is no rule
of three". Maybe over time it will sink in.

On 26/09/2023 17:57, Bart wrote:
> On 26/09/2023 16:10, David Brown wrote:
>> On 26/09/2023 13:37, Anton Shepelev wrote:
>
>>>          if( test_1 ) stat_1;
>>>     else if( test_2 ) stat_2;
>>>     else if( test_3 ) stat_3;
>>>
>>
>> These are both wrong :-)
>>
>>
>>      if (test1) {
>>          stat_1;
>>      } else if (test2) {
>>          stat_2;
>>      } else if (test3) {
>>          stat_3;
>>      } else {
>>          ...
>>      }
>>
>> That is clearer than yours, and far more maintainable.  And any coding
>> standard with a care for safety, security or reliability, (such as
>> MISRA or JSF-AV mentioned in this thread) will insist on the braces here.
>
> What is the actual rule about braces? Because you've clearly missed some
> out there, in omitting them around the first two 'else' branches.

It is certainly /possible/ to put in more braces (that is possible in a
great many places in C code). And you do have a valid argument for
consistency.

However, "else if" can be viewed as the C equivalent of "elseif" or
"elsif", as found in some other languages. This leads itself to a
simple and clear pattern like this. Sometimes such patterns can be more
important for clarity than the general rules.

>
> If you saying this is OK, then that's playing fast and rule with any
> such rule that braces must always be used even around one statement.
>

You are correct that my rules (and most people's rules) for braces are
not quite simple.

I am also quite happy with simple, short and unambiguous (no macros)
statements on the same line :

if (!p) return;

if (x > 0) x--;

But if things are more complex - the conditional is larger, the
statement is not "simple" (I admit that I am not defining "simple"
here), or the total line is getting too long, then I put in the braces
and indentation. Spilling to a second line without having the braces is
definitely wrong.

On 26/09/2023 18:40, Kaz Kylheku wrote:
> On 2023-09-26, Bart <bc@freeuk.com> wrote:
>> On 26/09/2023 16:10, David Brown wrote:
>>> On 26/09/2023 13:37, Anton Shepelev wrote:
>>
>>>>          if( test_1 ) stat_1;
>>>>     else if( test_2 ) stat_2;
>>>>     else if( test_3 ) stat_3;
>>>>
>>>
>>> These are both wrong :-)
>>>
>>>
>>>     if (test1) {
>>>         stat_1;
>>>     } else if (test2) {
>>>         stat_2;
>>>     } else if (test3) {
>>>         stat_3;
>>>     } else {
>>>         ...
>>>     }
>>>
>>> That is clearer than yours, and far more maintainable.  And any coding
>>> standard with a care for safety, security or reliability, (such as MISRA
>>> or JSF-AV mentioned in this thread) will insist on the braces here.
>>
>> What is the actual rule about braces? Because you've clearly missed some
>> out there, in omitting them around the first two 'else' branches.
>
> The actual rules is that the required braces, comprising a compound
> statement, can be prefixed by something which modifies the statement
> into a conditional.
>>
>> If you saying this is OK, then that's playing fast and rule with any
>> such rule that braces must always be used even around one statement.
>
> Indeed, I myself sometimes writes in a style like the following:
>
> if (condition) {
> /* loop not needed */
> } else for (...) {
>
> }
>
> The else keyword needs a statement, and the for statement
> satisfies it. It has braces of its own, so everything is cool.

I would not go that far. "else if" in C is, to me, a short form for
"elseif" or "elsif" found in other languages. I've never seen an
"elsefor" or "elsewhile" keyword.

"if, else if, else" chains are common and fit a nice pattern. But a
"for" loop is completely different, breaking the pattern - I'd have it
in its own braces :

if (...) {
...
} else {
for ( ... ) {
...
}
}

>
> The for (...) header is effectively a statement prefix which indicates
> iteration of that statement.
>
> In my style, I allow the braced statement to be prefixed not only
> by if (...) but other, similar statement introducers/prefixes
> like while (...) and switch.
>
> I don't think I've ever written a
>
> if (this) {
>
> } else do {
>
> } while(...);
>
> But I totally might. :)

Eek!

>
> What I wouldn't write is:
>
>
> if (condition) {
> /* loop not needed */
> } else for (...)
> body_expression_statement;
>
> Or, let alone:
>
> if (condition) {
> /* loop not needed */
> } else for (...)
> /* empty */;
>

No, indeed.

> Some languages combine "else" and "if" into a single token, even.
> The C preprocessing language is like that: #elif.
>

On 27/09/2023 03:43, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> I wonder how big a deal it would have been to introduce an actual
>> 'else-if' token? I expect it would look something like _Elseif; just
>> using a the hypenated 'else-if' would be better!
>
> A hyphenated keyword?

It would be three consecutive tokens: else, -, if, treated as though
there was a dedicated 'elseif' keyword. The advantage is that it
requires no new keyword.

> In various languages, I've seen "elif", "elsif", and "elseif".
> I'd be fine with any of those.
>
> But though I think it would have been nice to add such a keyword from
> the beginning, I'm not convinced it would be worth doing now. It's
> already perfectly possible to write long if/else chains in C:
>
> if (...) {
> ...
> }
> else if (...) {
> ...
> }
> else if (...) {
> ...
> }
> else {
> ...
> }

> (I know some people prefer to put the else on the same line as the {.
> That's not really the point.)

> Even though the indentation doesn't strictly reflect the grammar, it's a
> common enough idiom that that doesn't bother me.

It bothers /me/ because it's not pure. Because, if you write translation
rules, the nested nature of the chain is still there.

Both 'else if' and 'else { if' sequences are encountered in source code.

Because sometimes 'else' is followed by one statement, sometimes by
more, or you want the possibility that the one statement can be expanded
to more, or temporarily commented out.

You get that flexibility by having a strict rule that an 'if' statement
always looks like one of these:

if (cond) {...}
if (cond) {...} else {...}

and not for example like this:

if (cond) {...} else if (cond2) {...}

On 26/09/2023 19:46, Bart wrote:
> On 26/09/2023 17:40, Kaz Kylheku wrote:
>> On 2023-09-26, Bart <bc@freeuk.com> wrote:
>>> On 26/09/2023 16:10, David Brown wrote:
>
>>> What is the actual rule about braces? Because you've clearly missed some
>>> out there, in omitting them around the first two 'else' branches.
>>
>> The actual rules is that the required braces, comprising a compound
>> statement, can be prefixed by something which modifies the statement
>> into a conditional.
>
> But then that compound statement becomes a single statement with no
> braces of its own, and many of the problems associated with optional
> braces return.
>
>>> If you saying this is OK, then that's playing fast and rule with any
>>> such rule that braces must always be used even around one statement.
>>
>> Indeed, I myself sometimes writes in a style like the following:
>>
>>    if (condition) {
>>      /* loop not needed */
>>    } else for (...) {
>>
>>    }
>>
>> The else keyword needs a statement, and the for statement
>> satisfies it. It has braces of its own, so everything is cool.
>
> Suppose you were to write it like this:
>
>
>     } else
>         for (...) {
>
> then someone adds an extra statement:
>
>     } else
>         puts("Loop follows.");
>         for (...) {
>
> Now it's not so cool.
>

Exactly. The "else if" shortcut, IMHO, should only ever be for "else
if", and the attached actions need to be in braces. Then there are no
ambiguities, and minimal risk for mistakes if someone adds to the code
later.

> Really, it's quite silly: how far deep inside a series of /single/
> nested statements are you allowed to go, to enable you to claim that
> your 'else' branch is actually brace-delimited?
>
>
>> What I wouldn't write is:
>>
>>
>>    if (condition) {
>>      /* loop not needed */
>>    } else
>
> Why wouldn't you write this? Presumably something might be added there
> in future, otherwise it's a poorly thought-out condition.

I assumed from his post (Kaz can correct me if I'm wrong) that it was
the second half of that example that he saw as a problem. The full case
was :

if (condition) {
/* loop not needed */
} else for (...)
/* empty */;

To me, there are several things wrong here - so I certainly won't write
it. But empty bodies in conditionals do turn up sometimes, if that's
the clearest way to write the conditionals. They can be a good
placeholder for comments explaining the reasoning in the code, or - as
you suggest - for possible future additions.

if ((x >= 0) && (y >= 0)) {
// Both non-negative, so nothing to do here
} else if (x >= 0) {
y = x; // Fix negative y
} else if (y >= 0) {
x = y; // Fix negative x
} else {
panic(); // x and y should not both be negative
}

Of course the ordering could be changed, or the tests could be
re-arranged, so that the empty statement is not needed. But sometimes
code clarity suggests a pattern including empty statements.

I will even write something like this on occasion :

if (<complicated condition>) {
// Everything is fine, nothing to do
} else {
do_something();
}

rather than

if (!(<complicated condition>)) {
do_something();
}

It is all about what is clearest to read.

>
>> Some languages combine "else" and "if" into a single token, even.
>> The C preprocessing language is like that: #elif.
>
> This has always puzzled me, where C's preprocessor has a more grown-up,
> more solid , more readable and less error prone syntax than the main
> language. No dangling 'else' there!
>

C doesn't need an "elseif", since it has "else if" that does exactly the
same job. There are no circumstances (AFAICS) where you could use an
"elseif" keyword but not "else if".

For the preprocessor, you could not have "#else #if", thus you need a
separate preprocessor directive.

On 27/09/2023 10:23, David Brown wrote:
> On 26/09/2023 18:40, Kaz Kylheku wrote:

>> The else keyword needs a statement, and the for statement
>> satisfies it. It has braces of its own, so everything is cool.
>
> I would not go that far.  "else if" in C is, to me, a short form for
> "elseif" or "elsif" found in other languages.  I've never seen an
> "elsefor" or "elsewhile" keyword.

My language has 'if-elsif', 'case' and 'switch' selection statements
which can each have arbitrarily long sequences of tests.

Each can have an optional 'else' branch. (When used inside an
expression, which is not often, the whole thing returns a value so the
'else' is needed.)

Now, brace yourself... sometimes a series of tests changes between if,
case and switch, so I allow these to be mixed within the same statement:

if c1 then
elsif c2 then
elsecase x1
...
elsif c3 then
...
elseswitch x2
...
end

This just saves having deeply nested statements when the testing pattern
is really linear.

I don't have elsefor, that never comes up and doesn't make sense. But I
do have looping forms of switch/case called doswitch and docase, which
are used extensively.

(My 'switch' has the same restrictions as C's, plus it must be
implementable as a jump table. 'case' has the same syntax, but no
restrictions, and testing is sequential.)

David Brown:

> But sometimes
> code clarity suggests a pattern including empty statements.
>
> I will even write something like this on occasion :
>
> if (<complicated condition>) {
> // Everything is fine, nothing to do
> } else {
> do_something();
> }
>
> rather than
>
> if (!(<complicated condition>)) {
> do_something();
> }

Sometimes my arrangement is decided by which conditional
expression is simpler. When the branches are extremely
unbalanced, that is one is one is very long and the other a
one-liner, I will put the short one into the then-clause,
because the layout is better:

if( <condition> ) one_liner(); if( <condition> )
else { a = rather(long);
{ a = rather(long); and(cumbersome);
and(cumbersome); multiline();
multiline(); paragraph(of);
paragraph(of); code();
code(); }
} else one_liner();

When two thrirds of a long function is the code of some
special conditional processing, sometimes I prefer to jump
over it with a `goto' to save a level of indentation:

function struct baz ver_1(int b) function struct baz ver_1(int b)
{ int a = normal_proc_1(b ); { int a = normal_proc_1(b );
int c = normal_proc_2(a, b); int c = normal_proc_2(a, b);
if( special ) if( !special ) goto SKIP_SPECIAL;
{ spec_t = spec_init(a,c);
if( special_test(s) ) spec_t s = spec_init(a,c);
{ s1 = do_foo(s); if( special_test(s) )
s2 = do_bar(s); { s1 = do_foo(s);
if( s1 > s2 ) s2 = do_bar(s);
{ c = calc_c(a, s1, s2,); if( s1 > s2 )
many(); { c = calc_c(a, s1, s2,);
more(); many();
lines(); more();
here(); lines();
} here();
} }
special_finalize(c); }
} special_finalize(c);
temp = finalize(c); SKIP_SPECIAL:
if( test( temp ) ) temp = finalize(c);
{ update(c); } if( test( temp ) )
return c; { update(c); }
} return c;
}

Do all present vehemently condemn this practice?
Christopher Seiwald's seventh pillar seems to encourage
it[1]:

The left edge of the code defines its structure, while
the right side holds the detail. You must fight
indentation to safeguard this property. Code which moves
too quickly from left to right (and back again) mixes
major control flow with minor detail.

Forcibly align the main flow of control down the left
side, with one level of indentation for
if/while/for/do/switch statements. Use break, continue,
return, even 'goto' to coerce the code into left-side
alignment. Rearrange conditionals so that the block with
the quickest exit comes first, and then return (or break,
or continue) so that the other leg can continue at the
same indentation level.

> For the preprocessor, you could not have "#else #if", thus
> you need a separate preprocessor directive.

I think this is possible, but only hierarchically:

#if M1
...
#else
#if M2
...
#else
#if M3
...
#endif
#endif
#endif

Therefore, #elseif is introduced not to add a new possiblity
but to let the programmer express what was already possible
in a layout that better reflects his intent.
____________________
1. <https://web.archive.org/web/20100227185627/http://www.perforce.com/perforce/papers/prettycode.html>

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Bart:

> Now, brace yourself... sometimes a series of tests changes
> between if, case and switch, so I allow these to be mixed
> within the same statement:
>
> if c1 then
> elsif c2 then
> elsecase x1
> ...
> elsif c3 then
> ...
> elseswitch x2
> ...
> end
>
> This just saves having deeply nested statements when the
> testing pattern is really linear.

It looks awkward to me, especially without any horisontal
alignment, but your rationale is sound: the concept of
chaining branching statements is orthogonal to the the kind
individual statements, so that mixing them must be logical.

> (My 'switch' has the same restrictions as C's, plus it
> must be implementable as a jump table. 'case' has the same
> syntax, but no restrictions, and testing is sequential.)

You said upthread that one of your multiple-select
statements was more like SQL's CASE, i.e. able to dispatch
by condition /and/ by a value.

For lack of a special provision for a linear if-else chains,
I sometimes use a sequence of normal `if' statements with
`goto':

if( c1 ) { x = v1 ; goto X_SET; }
if( c2 ) { x = v2 ; goto X_SET; }
if( c3 ) { x = v3 ; goto X_SET; }
x = v_def;
X_SET:
/* continue with x ... */

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 27/09/2023 10:37, David Brown wrote:

> I will even write something like this on occasion :
>
>     if (<complicated condition>) {
>         // Everything is fine, nothing to do
>     } else {
>         do_something();
>     }
>
> rather than
>
>     if (!(<complicated condition>)) {
>         do_something();
>     }
>
> It is all about what is clearest to read.

I have a version of 'if' called 'unless', which sometimes reads better,
but not always.

In particular, although 'unless' can have an 'else' branch, it doesn't
have 'else-unless'; I couldn't work out what it meant!

Also, while C has 'do...while', my equivalent is 'repeat...until', with
the opposite logic.

I can't have repeat...while as that is ambiguous: the 'while' could be
starting a new loop. Actually I had some troubling figuring out how C
manages to avoid the same problem.

(Note that I can write C's

do {a;b;c;} while (cond);

as:

while a;b;c; cond do end

Ugly, though.)

On Wednesday, 27 September 2023 at 13:28:15 UTC+1, Anton Shepelev wrote:
> Bart:
> > Now, brace yourself... sometimes a series of tests changes
> > between if, case and switch, so I allow these to be mixed
> > within the same statement:
> >
> > if c1 then
> > elsif c2 then
> > elsecase x1
> > ...
> > elsif c3 then
> > ...
> > elseswitch x2
> > ...
> > end
> >
> > This just saves having deeply nested statements when the
> > testing pattern is really linear.
> It looks awkward to me, especially without any horisontal
> alignment, but your rationale is sound: the concept of
> chaining branching statements is orthogonal to the the kind
> individual statements, so that mixing them must be logical.
> > (My 'switch' has the same restrictions as C's, plus it
> > must be implementable as a jump table. 'case' has the same
> > syntax, but no restrictions, and testing is sequential.)
> You said upthread that one of your multiple-select
> statements was more like SQL's CASE, i.e. able to dispatch
> by condition /and/ by a value.
>
> For lack of a special provision for a linear if-else chains,
> I sometimes use a sequence of normal `if' statements with
> `goto':
>
> if( c1 ) { x = v1 ; goto X_SET; }
> if( c2 ) { x = v2 ; goto X_SET; }
> if( c3 ) { x = v3 ; goto X_SET; }
> x = v_def;
> X_SET:
> /* continue with x ... */
>
I'd find that confusing. Are c1, c2, c3 mutually exclusive? If so, why are they
separate conditions? If more than one is true, the first option is chosen. But
why?

On 26/09/2023 19:53, Anton Shepelev wrote:
> David Brown to Anton Shepelev:
>
>>> Modern languages with multiple returns or tuples provide
>>> a partial solution, another being to unify error info
>>> with the result of successful execution in dynamic
>>> languages or ones with templates (to save the declaring
>>> a combined TResult type for every function). But then,
>>> I loose the whole pupose of an error flag -- the ability
>>> to invoke funtions inside an `if' statement.
>>
>> You realise that in C you can return structs, and thus
>> include status returns as well as value returns in one
>> item?
>
> I do, which is why I wrote about defining a
> <func_name>TResult type for /every/ function.

You don't need a separate type for each function.

> If, on the
> other hand, I define TResult to contain only error
> information and the success flag, I save a single parameter
> compared to returning the success flag and error info
> separately.
>
>> Still, why are you talking about modern languages and
>> object oriented programming when you insist on using a
>> language outdated a generation ago?
>
> Because C lacks those new features and I am spared the
> pressure to use them in my code :-) Seriously, I see nothing
> bad in considering alternative approaches to get out of the
> box, so to say... I do not think C is outdated a generation
> ago, and even the new standards have far from changed it
> beyond recognition. It is basically the same language.

Thinking about alternatives is always a good idea.

No, C is not outdated (though there are better choices for many of the
programming tasks that used to be done in C). But C90 /is/ outdated,
and has been for a very long time.

>
>>> Linus 8-chareater-tab Torvalds was IMHO right when he
>>> decreed that a function shall not have more then three
>>> levels of nesting, his enourmous tab serving as a dumb,
>>> primitive, mechanical, and ugly means of enforsing this
>>> decree.
>>
>> No, Linus was wrong - as he is on many things. (He's
>> right on many things too, of course.) We are not using
>> typewriters, we are not using 80x25 character displays,
>> and we do not need to have pointless limitations.
>
> They are not pointless. 80 characters is a generous the
> upper limit of a compfortable line width, most typographical
> manuals suggesting lower lengths, and I did not refer to the
> 25-line limit anywhere. My functions are frequently longer.

No, 80 characters is not a comfortable line width limit. It is very
artificial, and limits the use of longer identifiers or occasional
naturally longer lines. Remember, line width limits in programming are
not remotely the same as letter counts per line in prose text.

>
>> I don't advocate for deeply nested or overly complex
>> functions, of course - I advocate for clear code with
>> immediately obvious blocks indicated by braces /and/
>> indents. And if clear code requires more than 3 levels of
>> nesting, use that.
>
> In my opinion, up to three levels are easy to perceive, and
> then it becomes harder epxonentially: four levels is
> tolerable and five is a mess.
>

In reality, it depends on the code and the structure, as well as the
familiarity for the programmer. There's no doubt that deeper nesting
gets harder to follow, all other things being equal. But all other
things are often /not/ equal. Good indentation is hugely easier to
interpret than flat unindented code, or strange "outdented" styles. If
there is a clear pattern to a piece of code, then deeply nested code
will be perfectly comprehensible.

/Most/ code probably needs no more than three levels of indentation (in
addition to the indentation for the function body). But that follows
from the principle of avoiding doing too much in one function, rather
than any fixed rule for indentation limits.

All you achieve by putting arbitrary limits on these things is that the
occasions where longer lines, or deeper nesting, or bigger functions
would result in clearer code, now have to be artificially divided up in
less clear ways. It doesn't help for most code, which will already be
well within whatever limits you pick, but it means that less common code
is worse off.

>>> For an example, and the standard if-else-if-else...
>>> chain is in fact a variant of a switch, and a switch has
>>> the
>>
>> Not in C.
>
> Yes, I meant the broader condept of switch as a table of
> tests and corresponding statements, with perhaps a fallback
> (default) entry. The point is that the sturcture of switch
> is a table with two columns (see below).
>
>>> if( test_1 ) {
>>> stat_1 } else {
>>> if( test_2 ) {
>>> stat_2 } else {
>>> if( test_3 ) {
>>> stat_3 } else {
>>
>> I have never seen if-else chains formatted that way - it
>> is clearly incorrect indentation.
>
> It is technically /the one true/ correct indentation,
> because each level of nesting has its own indent.

Again - I have never seen if-else if-else chains formatted that way. If
you think it is "technically" following the rules, then you have
misunderstood the rules, or whoever gave you the rules (perhaps me)
oversimplified them. The point of style rules is to give clear and
consistent visual formatting that minimises the risk of misunderstanding
or making errors - they are not designed to give simplistic but absolute
rules that result in incomprehensible monstrosities.

The additional rule here can be thought of as treating "else if" as
though it were an "elseif" keyword.

>
>> if (test1) {
>> stat_1;
>> } else if (test2) {
>> stat_2;
>> } else if (test3) {
>> stat_3;
>> } else {
>> ...
>> }
>
> Now, you have recoginised that although syntatically it is a
> deeply nested unblananced tree, semantically it is a linear
> structure, and therefore you flattened it, so that the
> nesting level is no longer equal to the indent. Does a dumb
> pretty-printer understand semantics? Do coding standards
> care about semantics?

Of course pretty-printers take semantics into account. Except for a few
points (such as line continuation, and single-line comments), all white
space is syntactically equivalent to a single space character in C, and
most such spaces have no syntactic meaning at all. "Pretty printing" is
all about making the visual appearance match the semantics of the code,
while keeping the syntax unchanged.

>
>>> if( test_1 ) stat_1;
>>> else if( test_2 ) stat_2;
>>> else if( test_3 ) stat_3;
>>>
>>> It shorter, clearer, and better structured, because the
>>> programmer has formatted the code according its intent.
>>> Observe also the indent of the first `if' to have it
>>> aligned with the other entries of the table.
>>
>> That's a strawman argument, because no one would ever
>> write an if-else chain the way you first suggested.
>

To be clear here - your comparison of your choice of formatting with
your unbalanced tree version is a strawman argument, because no one
would ever write the unbalanced tree version. A comparison to the
linear structure that I gave would not be a strawman argument, because
it is the form that many people use in real code.

> No, what /you/ say after `because' is a strawman argument
> becase it appeals to external circumstances (the number of
> followers) rather than criticises the formatting itself. I
> will try to explain my formatting again: the structure of
> that control statement is a table with two columns and three
> rows. A careful programmer, having respect for the reader,
> will therefore take advantage of the 2-dimensional nature of
> text and format it in a 2x3 grid, aligning the correspondent
> parts together:
> test_1 stat_1
> test_2 stat_2
> test_3 stat_3
>
> It is only meet also to alignt the correspondent keywords,
> as I have done above. This is the only way to express the
> programmer's intent in the formatting. Curly braces would
> be redundant, because the structure is sufficiently
> transparent not to require them, but you can add them
> anyway:
> if( test_1 ) { stat_1 ; }
> else if( test_02 ) { stat_02 ; }
> else if( test_003 ) { stat_003; }
>
> I have introduced indentifiers of varying length to show the
> correct horisontal alignment of closing parentheses, curly
> braces, and semicolons.
>

Malcolm McLean to Anton Shepelev:

> > For lack of a special provision for a linear if-else
> > chains, I sometimes use a sequence of normal `if'
> > statements with `goto':
> >
> > if( c1 ) { x = v1 ; goto X_SET; }
> > if( c2 ) { x = v2 ; goto X_SET; }
> > if( c3 ) { x = v3 ; goto X_SET; }
> > x = v_def;
> > X_SET:
> > /* continue with x ... */
>
> I'd find that confusing. Are c1, c2, c3 mutually
> exclusive? If so, why are they separate conditions? If
> more than one is true, the first option is chosen. But
> why?

Thay may or may not be mutually exclusive. My point is,
that whichever the case, the code above behaves identically
to the if-else chain:

if( c1 ) x = v1 ;
else if( c2 ) x = v2 ;
else if (c3 ) x = v3 ;
else x = v_def;

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 27/09/2023 12:37, Malcolm McLean wrote:
> On Wednesday, 27 September 2023 at 10:05:12 UTC+1, David Brown wrote:
>> On 26/09/2023 17:29, Malcolm McLean wrote:
>>> On Tuesday, 26 September 2023 at 16:11:07 UTC+1, David Brown wrote:
>>>> On 26/09/2023 13:37, Anton Shepelev wrote:
>>>>>
>>>>> Linus 8-chareater-tab Torvalds was IMHO right when he
>>>>> decreed that a function shall not have more then three
>>>>> levels of nesting, his enourmous tab serving as a dumb,
>>>>> primitive, mechanical, and ugly means of enforsing this
>>>>> decree.
>>>> No, Linus was wrong - as he is on many things. (He's right on many
>>>> things too, of course.) We are not using typewriters, we are not using
>>>> 80x25 character displays, and we do not need to have pointless
>>>> limitations. I don't advocate for deeply nested or overly complex
>>>> functions, of course - I advocate for clear code with immediately
>>>> obvious blocks indicated by braces /and/ indents. And if clear code
>>>> requires more than 3 levels of nesting, use that.
>>>>
>>> Rule of three. Three levels of nesting or indirection. Because we live in a three
>>> dimensional world.
>> Rule of seven. Seven levels of nesting or indirection. Because we have
>> seven days in the week.
>>
>> See? Anyone can write complete and utter drivel, with totally
>> nonsensical "justifications".
>>
>> Don't you ever get tired of spouting these insane platitudes, as though
>> you imagine yourself as some kind of holy prophet of programming? Your
>> track record here, and the way you make such pronouncements as if you
>> were revealing the hidden laws of the universe, makes people assume you
>> are wrong. Even though you are sometimes accidentally correct, or at
>> least partially right, the gut reaction is that Malcolm is pontificating
>> again, so its nonsense.
>>
>> Please put a post-it note on the top of your screen - "There is no rule
>> of three". Maybe over time it will sink in.
>>
> It is odd that singificant figures in the programming world seem to have a
> habit of agreeing with me.
> Maybe consider that maybe Malcolm is more correct than he is wrong and
> that you, David Brown, can sometimes learn something.
>

I've considered it, and I have concluded that you are wrong more often
than you are right in these things. Or, to be more precise, you are
wrong in your absolutist ideas ("three is good, four is bad"),
unjustified in your rationalisation for your ideas (they are often
totally absurd), and your appeals to authority never hold up.

I am quite happy to agree that too many levels of nesting makes code
harder to understand. I am happy to agree that for a lot of code, three
levels of nesting (not including indents for functions, classes, etc.)
is usually sufficient. I can even agree that deeper nesting than that
may be a sign that the function would be better if it were organised
somewhat differently, or split up.

But that does /not/ mean that three levels of nesting is any kind of
absolute limit, or cut-off point. It does not mean that three levels is
always clear, or that four levels are always bad - it merely means that
too many levels makes code harder to follow.

There is no mythical "rule of three" here, or anywhere else. You cannot
simply take everything that you can think of that is related to the
number 3, and lump it together as though there is a divine purpose
linking them all. It's the same nutjob mentality that gives us
flat-earthers.

> (Nesting, indirection, and dimensioning are all related to each other).

No, they are not.

None of this means you are always wrong, nor does it mean I can't learn
from things you write. But it does mean that it can take some effort to
separate your fairytale nonsense from your rational and relevant points.

You have plenty of useful and interesting things to say, and things we
/can/ learn from. Please stop distracting from that with your imaginary
rules and even more unrealistic explanations for them.

On Wednesday, 27 September 2023 at 16:03:35 UTC+1, David Brown wrote:
> On 27/09/2023 12:37, Malcolm McLean wrote:
>
> > (Nesting, indirection, and dimensioning are all related to each other).
> No, they are not.
>
You haven't thought this through, have you?