Re: Loops (was Re: do { quit; } else { })

On 22/04/2025 22:03, bart wrote:

On 22/04/2025 20:26, Kaz Kylheku wrote:

On 2025-04-22, bart <bc@freeuk.com> wrote:

 

Or would you automatically say it was reasonable no matter how many
levels there were, just to disagee with me and to side with a fellow C
programmer?

>
You're trying to say that C is a bad language because you can have
7 or more layers of macro expansion, but you're not considering how
bizarre and crippling restriction it would be to put a cap on it.

 Here, I'm trying to determine if this is the poster's honest, objective opinion, or whether they'd always going to be defend such code no matter what.
 14 levels of macros? No problem; I'm sure there was a good reason!

If there is good reason for 14 levels of macros, then fine.
If there are not /good/ reasons for multiple levels, but the result is correct code that compiles efficiently (on reasonable compilers with reasonable options), then maybe it is appropriate to leave it untouched.
Too few levels of functions and/or macros (there is no semantic difference between macros and functions in this matter) makes code hard to write and hard to get correct - you are doing too much at a time. Splitting things up - divide and conquer - is a big win.  But too many levels also makes it hard to see what is going on and can be a maintenance challenge.
So once you first have too many levels - for whatever reasons - and the code is correct and does the job, you have to decide whether or not to refactor into simpler, neater and clearer code.  The result would be easier to maintain in the future, but it has a cost in time, effort and the risk of making mistakes.

 I did ask at one point whether anybody could link to some truly terrible C code; nobody has so far.

There are probably two reasons for that.  One is that everyone, except perhaps you, understands that this is very subjective.  I've seen plenty of code posted in this group, written by regulars whose programming skill and knowledge I highly respect, and yet which I would classify as "truly terrible" and reject it immediately if it were presented to me for code review in my work.  The other reason is that nobody else is particularly interested in seeing bad code, or going out of their way to look for it.

 I just want to find out the threshold at which some will actually agree that macros have been abused or their use is over the top and unjustified.
 

Why?
We are all going to have different first-glance opinions on different bits of code.  But to form a solid, justifiable opinion I would want to see a lot more of the code in question.  I'd want to look at the macro definitions, and how they are used in the code - the macros alone are far from enough.  I'd want to know the history of the project.  I'd want to know the target usage of the code.  I'd want to see its documentation, its roadmap for the future, its history of bugs and other problems.  I'd want to know more about the developers behind the code. I'd want to know if other people are expected to read the code, to work with it, to re-use it, or if they would simply see it as a finished product.  I'd want to know if it is targeting a specific device, OS, processor, compiler, or if it is intended to be portable.  I'd want to know how it is tested.  I'd want to know if it is viewed as low-risk, low-cost software, or intended to be secure or highly reliable.
Clearly, I haven't the slightest interest in going to that effort just to please you.
So the best I can offer you is a very cursory glance at the code, and the opinion that - in the case of the Lua source code snippet - it's probably fine, but a bit more finely divided than I would like myself, though there may be good reasons behind that.
I really can't see what any of that gives you.
We all know that some people write bad code, or have written bad code. I don't think anyone will deny that.  We also all have different thoughts and experiences on what makes code good or bad, or when bad code might be perfectly acceptable - all such judgements are very subjective, and therefore of little use here.
And we all know this is entirely independent of programming language.

There doesn't seem to be any limit - or not any that they want to admit to me.

It is absolutely correct that there is no dividing line between "good code" and "bad code", or "use" and "abuse".

   > but you're not considering how
 > bizarre and crippling restriction it would be to put a cap on it.
 There WILL be a cap.

No.
Very few things in this world are black-or-white.

Some deep nesting might be justified in special cases, for example some recursive macro that builds a string a character at a time.
 But this was not such a case; it was simply decided to make it work using macros instead of functions.

How do you know that?

 As for being crippling: I've written all sorts of language apps, including interpreters like this, without ever using more than one level, and for several decades, zero levels.
 

And how do you know that is a good choice, or would be better in this case?

A language like C provides all these odd-ball features, people are going to use them.

Macros are hardly odd-ball.