On 23/09/2023 18:13, Anton Shepelev wrote:
> David Brown:
>
>> I made a post with multiple reasons why I personally think
>> it is a bad choice -- if you have the opportunity, I think
>> it would be interesting to hear why you think differently.
>> You could add to that list your reasons why you think
>> being able to write C90 code is a good thing. (I'm not
>> saying you are wrong, merely that your preferences are
>> different, and I am curious as to why.)
>
> Yes, I remembered it. Answered five or so minutes ago, but
> (I fear) not to your satisfaction...
>

It was certainly to my satisfaction - I was looking for your reasons for
your choices, not for agreement with /my/ reasons for /my/ choices, and
that's what you gave. (Of course, I'd also be quite happy if you read
my post and changed your mind to agree with me :-) )

On 25/09/2023 07:43, David Brown wrote:
> On 23/09/2023 18:05, Anton Shepelev wrote:

>>    2.  Upon encountering a new variable, the reader can
>>        glance at the top of function to find its type and
>>        desctiption, whereas intermixed style is requires
>>        scanning the entire text, unless, of course, you count
>>        IDE helper tools, which I do not.  Code should read
>>        smooth off a printed page.
>
> No, you are completely wrong here.
>
> With your style, the reader encountering a new variable has to deal with
> two wildly separate parts of the text - the definition at the start of
> the function, and the use of the variable in the code.  It is particular
> bad for large functions or when you have a small screen or window (this
> can be the case when you are debugging, for example), and you have to
> scroll around.

I've spent a few days working with C codebases where I have exactly that
problem: figuring out the details of a typedef, struct, enum, global
variable, function or macro, used in a function, which might be declared
not only 100s or 1000s of lines earlier, but in one of a dozen include
files.

So yes, that happens anyway, but on a big scale. I wish it WAS only at
the start of function that I have to look!

To go back to one of the points I made in those links: suppose I define
a typedef say at module scope to be shared by functions 35, 62 and 78 of
100 functions in that module.

Where should I place that typedef: before the definition of function 1,
or immediately before function 35 since that is where it is first used?

Because I rarely see functions, global variables and typedefs mixed up
like that. Maybe it's the next big thing.

Anyway, it is that segregation that I like to see within a function too.

On 25/09/2023 12:51, Bart wrote:
> On 25/09/2023 07:43, David Brown wrote:
>> On 23/09/2023 18:05, Anton Shepelev wrote:
>
>>>    2.  Upon encountering a new variable, the reader can
>>>        glance at the top of function to find its type and
>>>        desctiption, whereas intermixed style is requires
>>>        scanning the entire text, unless, of course, you count
>>>        IDE helper tools, which I do not.  Code should read
>>>        smooth off a printed page.
>>
>> No, you are completely wrong here.
>>
>> With your style, the reader encountering a new variable has to deal
>> with two wildly separate parts of the text - the definition at the
>> start of the function, and the use of the variable in the code.  It is
>> particular bad for large functions or when you have a small screen or
>> window (this can be the case when you are debugging, for example), and
>> you have to scroll around.
>
> I've spent a few days working with C codebases where I have exactly that
> problem: figuring out the details of a typedef, struct, enum, global
> variable, function or macro, used in a function, which might be declared
> not only 100s or 1000s of lines earlier, but in one of a dozen include
> files.
>
> So yes, that happens anyway, but on a big scale. I wish it WAS only at
> the start of function that I have to look!

In all code, beyond "Hello, world!" programs, you will need to look in
different parts of the code base when you need more details. There is
no escape from that, in any language.

So you have to do what you can to reduce the effort involved here. (And
not everyone is good at that - please do not blame /me/ for sub-optimal
code organisations in some project you have found.)

Putting your local variable definitions at the point where they have an
initial value, preferably keeping them const, and using minimal
reasonable scopes, will all reduce this effort.

But that is only part of the picture. Use clear header files containing
only the code necessary, with corresponding implementation files that
make everything "static" unless the variable/const/function is
"exported" in the header file. Divide the code into multiple files, in
logical partitions. Use multiple source directories if the project is
big enough. Use good names for everything - files, types, functions,
data, etc. Smaller scope items can have shorter names, bigger scope
items need more descriptive names. Use the best tools you can get hold
of - use good IDE's or editors. Document the code as well as you
reasonably can, based on appropriate needs for the project. Preferably
this should involve automated code documentation tools like doxygen to
minimise the risk of code and documentation mismatches, to reduce the
effort involved in the documentation (writing documentation is rarely
the fun part of development!), and to generate caller/callee/include
graphs, cross-references, etc. Keep a good structure and clean
interfaces at all levels - divide and conquer.

(Using good tools almost invariably means using well established
languages - not necessarily C, but not obscure or rare languages.)

So I don't in any way claim that using proper local variables, defined
when they are used, solves all software development challenges. But it
is /part/ of the solution.

>
> To go back to one of the points I made in those links:

(I haven't read your links.)

> suppose I define
> a typedef say at module scope to be shared by functions 35, 62 and 78 of
> 100 functions in that module.
>
> Where should I place that typedef: before the definition of function 1,
> or immediately before function 35 since that is where it is first used?
>

That's a stupid question. Don't have 100 functions in your module.

In your 20 function module, if your typedef is used in functions 3, 9
and 17, then it's worth considering if the order of functions in the
module makes sense. Assuming it does, then common practice would likely
be placing it near the start of the module. (If the type is part of the
interface to exported code or data, then of course it must be placed in
the header file.)

> Because I rarely see functions, global variables and typedefs mixed up
> like that. Maybe it's the next big thing.
>

"global variables" - variables that are exported from a module - should
be declared in a header file, and are usually then defined at the start
of the implementation file. (Generally, heavy use of global variables
is frowned upon - they can give too tight coupling between different
modules.) Static file-scope data is often defined near the start of a
module, though I am quite happy to define it just before the functions
that use it, especially if there are only one or two and it is
effectively local state for the implementation.

> Anyway, it is that segregation that I like to see within a function too.

I know you do. You and Anton are far from alone in this. But I think
you both write poorer code because of it. (And if you disagree with the
reasons I gave, fair enough - it's your code, not mine.)

On 25/09/2023 14:40, David Brown wrote:
> On 25/09/2023 12:51, Bart wrote:

>> suppose I define a typedef say at module scope to be shared by
>> functions 35, 62 and 78 of 100 functions in that module.
>>
>> Where should I place that typedef: before the definition of function
>> 1, or immediately before function 35 since that is where it is first
>> used?
>>
>
> That's a stupid question.  Don't have 100 functions in your module.

Huh? I didn't realise that was that controversial. I don't actually know
how many functions I have per module, I've never counted!

But I've counted now, and my projects have 20-40 functions/module on
average. Library modules tend to have more (up to 100), and maximum was
220 functions in one file (handler functions for bytecode, and similar
modules where there is some sort of N-way dispatch going on).

Among C projects (not mine), the first couple I tried were 33 functions
average, 100 max (Lua), and 26 average/200 max (BBX).

LibJPEG averaged 9, but that also uses 70 files for a JPEG-handling
library, so it's rather spread out. You can implement JPEG encoders and
decoders in about one 1Kloc file each.

BTW sql.c (one-file sqlite3.c plus enough code to make a working app),
had 2300 functions on one file, with one of those functions being 7000
lines.

> In your 20 function module

So 20 is reasonable but not 100? OK.

I am aware of the line counts of my modules, and those probably average
1000 lines per module, with a max of 3-5Kloc.

I really don't think it's that critical. Is there a limit on how many
entries in one database before you have to split it up? Or how many
files in one folder? The entries belong together!

On 9/25/2023 10:56 AM, Bart wrote:
> On 25/09/2023 14:40, David Brown wrote:
>> On 25/09/2023 12:51, Bart wrote:
>
>>> suppose I define a typedef say at module scope to be shared by
>>> functions 35, 62 and 78 of 100 functions in that module.
>>>
>>> Where should I place that typedef: before the definition of function
>>> 1, or immediately before function 35 since that is where it is first
>>> used?
>>>
>>
>> That's a stupid question.  Don't have 100 functions in your module.
>
> Huh? I didn't realise that was that controversial. I don't actually know
> how many functions I have per module, I've never counted!

I think there is a complexity rule is MISRA that talks about this...

>
> But I've counted now, and my projects have 20-40 functions/module on
> average. Library modules tend to have more (up to 100), and maximum was
> 220 functions in one file (handler functions for bytecode, and similar
> modules where there is some sort of N-way dispatch going on).
>
> Among C projects (not mine), the first couple I tried were 33 functions
> average, 100 max (Lua), and 26 average/200 max (BBX).
>
> LibJPEG averaged 9, but that also uses 70 files for a JPEG-handling
> library, so it's rather spread out. You can implement JPEG encoders and
> decoders in about one 1Kloc file each.
>
> BTW sql.c (one-file sqlite3.c plus enough code to make a working app),
> had 2300 functions on one file, with one of those functions being 7000
> lines.
>
>> In your 20 function module
>
> So 20 is reasonable but not 100? OK.
>
> I am aware of the line counts of my modules, and those probably average
> 1000 lines per module, with a max of 3-5Kloc.
>
> I really don't think it's that critical. Is there a limit on how many
> entries in one database before you have to split it up? Or how many
> files in one folder? The entries belong together!
>

On 25/09/2023 19:03, Chris M. Thomasson wrote:
> On 9/25/2023 10:56 AM, Bart wrote:
>> On 25/09/2023 14:40, David Brown wrote:
>>> On 25/09/2023 12:51, Bart wrote:
>>
>>>> suppose I define a typedef say at module scope to be shared by
>>>> functions 35, 62 and 78 of 100 functions in that module.
>>>>
>>>> Where should I place that typedef: before the definition of function
>>>> 1, or immediately before function 35 since that is where it is first
>>>> used?
>>>>
>>>
>>> That's a stupid question.  Don't have 100 functions in your module.
>>
>> Huh? I didn't realise that was that controversial. I don't actually
>> know how many functions I have per module, I've never counted!
>
> I think there is a complexity rule is MISRA that talks about this...

Are there are also rules about how many lines in a function, and how
many modules in a program?

Minimising one will increase the number of functions, and minimising the
number of functions per module will increase the number of modules.

Further, there will be more complexity due to interactions or interfaces
between functions and between modules being exposed, that could have
been kept private.

On 9/25/2023 11:53 AM, Bart wrote:
> On 25/09/2023 19:03, Chris M. Thomasson wrote:
>> On 9/25/2023 10:56 AM, Bart wrote:
>>> On 25/09/2023 14:40, David Brown wrote:
>>>> On 25/09/2023 12:51, Bart wrote:
>>>
>>>>> suppose I define a typedef say at module scope to be shared by
>>>>> functions 35, 62 and 78 of 100 functions in that module.
>>>>>
>>>>> Where should I place that typedef: before the definition of
>>>>> function 1, or immediately before function 35 since that is where
>>>>> it is first used?
>>>>>
>>>>
>>>> That's a stupid question.  Don't have 100 functions in your module.
>>>
>>> Huh? I didn't realise that was that controversial. I don't actually
>>> know how many functions I have per module, I've never counted!
>>
>> I think there is a complexity rule is MISRA that talks about this...
>
> Are there are also rules about how many lines in a function, and how
> many modules in a program?
>
> Minimising one will increase the number of functions, and minimising the
> number of functions per module will increase the number of modules.
>
> Further, there will be more complexity due to interactions or interfaces
> between functions and between modules being exposed, that could have
> been kept private.

Fwiw, here the documentation that I am referring to:

https://www.stroustrup.com/JSF-AV-rules.pdf

On 25/09/2023 19:55, Chris M. Thomasson wrote:
> On 9/25/2023 11:53 AM, Bart wrote:
>> On 25/09/2023 19:03, Chris M. Thomasson wrote:
>>> On 9/25/2023 10:56 AM, Bart wrote:
>>>> On 25/09/2023 14:40, David Brown wrote:
>>>>> On 25/09/2023 12:51, Bart wrote:
>>>>
>>>>>> suppose I define a typedef say at module scope to be shared by
>>>>>> functions 35, 62 and 78 of 100 functions in that module.
>>>>>>
>>>>>> Where should I place that typedef: before the definition of
>>>>>> function 1, or immediately before function 35 since that is where
>>>>>> it is first used?
>>>>>>
>>>>>
>>>>> That's a stupid question.  Don't have 100 functions in your module.
>>>>
>>>> Huh? I didn't realise that was that controversial. I don't actually
>>>> know how many functions I have per module, I've never counted!
>>>
>>> I think there is a complexity rule is MISRA that talks about this...
>>
>> Are there are also rules about how many lines in a function, and how
>> many modules in a program?
>>
>> Minimising one will increase the number of functions, and minimising
>> the number of functions per module will increase the number of modules.
>>
>> Further, there will be more complexity due to interactions or
>> interfaces between functions and between modules being exposed, that
>> could have been kept private.
>
> Fwiw, here the documentation that I am referring to:
>
> https://www.stroustrup.com/JSF-AV-rules.pdf

That paragraph is in danger of breaching its own rule.

Look at this line from Lua sources:

luaC_barrier(L, clCvalue(s2v(L->ci->func.p)), fr);

(It's of dozens of instances causing problem for my compiler.)

It'a part of function of only 9 lines. It all seems simple enough. But
exactly is it doing?

It turns out those are macros not functions. A preprocessed version of
that line is:

((((fr)->tt_)&(1<<6))?(((((((&((((union
GCUnion*)(((((&(L->ci->func.p)->val))->value_).gc))))->cl.c))))->marked)&((1<<(5))))&&((((((fr)->value_).gc))->marked)&(((1<<(3))|(1<<(4))))))?luaC_barrier_(L,(&(((union
GCUnion*)((((&((((union
GCUnion*)(((((&(L->ci->func.p)->val))->value_).gc))))->cl.c))))))->gc)),(&(((union
GCUnion*)(((((fr)->value_).gc))))->gc))):((void)((0)))):((void)((0))));

This what *I* call complex, even though it is only one line.

On 25/09/2023 19:56, Bart wrote:
> On 25/09/2023 14:40, David Brown wrote:
>> On 25/09/2023 12:51, Bart wrote:
>
>>> suppose I define a typedef say at module scope to be shared by
>>> functions 35, 62 and 78 of 100 functions in that module.
>>>
>>> Where should I place that typedef: before the definition of function
>>> 1, or immediately before function 35 since that is where it is first
>>> used?
>>>
>>
>> That's a stupid question.  Don't have 100 functions in your module.
>
> Huh? I didn't realise that was that controversial. I don't actually know
> how many functions I have per module, I've never counted!
>

What is "too big" will, of course, vary significantly - there is no
fixed limit. But if you are having difficulty figuring out where to put
things in the file and be able to find them easily, it's too big.

If you want clear and easily navigable code, don't make your files too
big. It's as simple as that.

On 25/09/2023 20:53, Bart wrote:
> On 25/09/2023 19:03, Chris M. Thomasson wrote:
>> On 9/25/2023 10:56 AM, Bart wrote:
>>> On 25/09/2023 14:40, David Brown wrote:
>>>> On 25/09/2023 12:51, Bart wrote:
>>>
>>>>> suppose I define a typedef say at module scope to be shared by
>>>>> functions 35, 62 and 78 of 100 functions in that module.
>>>>>
>>>>> Where should I place that typedef: before the definition of
>>>>> function 1, or immediately before function 35 since that is where
>>>>> it is first used?
>>>>>
>>>>
>>>> That's a stupid question.  Don't have 100 functions in your module.
>>>
>>> Huh? I didn't realise that was that controversial. I don't actually
>>> know how many functions I have per module, I've never counted!
>>
>> I think there is a complexity rule is MISRA that talks about this...
>

I am pretty sure there is no such rule. I can't see it in my copy of
MISRA C 2012 (though I don't claim to be very familiar with the
document, so I might have missed something).

> Are there are also rules about how many lines in a function, and how
> many modules in a program?

There is the concept of "Cyclomatic complexity"
(<https://en.wikipedia.org/wiki/Cyclomatic_complexity>) which suggests
that overly complex functions become impossible to test or even to fully
comprehend.

>
> Minimising one will increase the number of functions, and minimising the
> number of functions per module will increase the number of modules.
>

There can certainly be tradeoffs, yes. Sometimes splitting things up
gives better refactorisation and more code reuse, reducing the overall
size. But the idea is to deal with manageable chunks at each level. If
you are having trouble finding information you need, you have probably
chosen the splits poorly - that could mean you have too many divisions,
or divisions in the wrong places, as well as possibly meaning your parts
are too big. It could also mean that you are looking for too much
detail at an inappropriate level - maybe knowing all the details of a
type or a function isn't actually important in order to use it correctly.

> Further, there will be more complexity due to interactions or interfaces
> between functions and between modules being exposed, that could have
> been kept private.

That can indeed be a factor. That is one of the reasons why I can't
give any fixed answers.

But if you tell me you have 100 functions in a module, with use of an
important type scattered randomly amongst them, and it's hard to know
where to put the type definition - then my first guess is the module is
too big. I might change that opinion when I know details of it and why
the code structure is this way, but that's my initial reaction.

On 9/25/2023 12:29 PM, David Brown wrote:
> On 25/09/2023 20:53, Bart wrote:
>> On 25/09/2023 19:03, Chris M. Thomasson wrote:
>>> On 9/25/2023 10:56 AM, Bart wrote:
>>>> On 25/09/2023 14:40, David Brown wrote:
>>>>> On 25/09/2023 12:51, Bart wrote:
>>>>
>>>>>> suppose I define a typedef say at module scope to be shared by
>>>>>> functions 35, 62 and 78 of 100 functions in that module.
>>>>>>
>>>>>> Where should I place that typedef: before the definition of
>>>>>> function 1, or immediately before function 35 since that is where
>>>>>> it is first used?
>>>>>>
>>>>>
>>>>> That's a stupid question.  Don't have 100 functions in your module.
>>>>
>>>> Huh? I didn't realise that was that controversial. I don't actually
>>>> know how many functions I have per module, I've never counted!
>>>
>>> I think there is a complexity rule is MISRA that talks about this...
>>
>
> I am pretty sure there is no such rule.  I can't see it in my copy of
> MISRA C 2012 (though I don't claim to be very familiar with the
> document, so I might have missed something).
>
>> Are there are also rules about how many lines in a function, and how
>> many modules in a program?
>
> There is the concept of "Cyclomatic complexity"
> (<https://en.wikipedia.org/wiki/Cyclomatic_complexity>) which suggests
> that overly complex functions become impossible to test or even to fully
> comprehend.
>
>>
>> Minimising one will increase the number of functions, and minimising
>> the number of functions per module will increase the number of modules.
>>
>
> There can certainly be tradeoffs, yes.  Sometimes splitting things up
> gives better refactorisation and more code reuse, reducing the overall
> size.  But the idea is to deal with manageable chunks at each level.  If
> you are having trouble finding information you need, you have probably
> chosen the splits poorly - that could mean you have too many divisions,
> or divisions in the wrong places, as well as possibly meaning your parts
> are too big.  It could also mean that you are looking for too much
> detail at an inappropriate level - maybe knowing all the details of a
> type or a function isn't actually important in order to use it correctly.
>
>> Further, there will be more complexity due to interactions or
>> interfaces between functions and between modules being exposed, that
>> could have been kept private.
>
> That can indeed be a factor.  That is one of the reasons why I can't
> give any fixed answers.
>
> But if you tell me you have 100 functions in a module, with use of an
> important type scattered randomly amongst them, and it's hard to know
> where to put the type definition - then my first guess is the module is
> too big.  I might change that opinion when I know details of it and why
> the code structure is this way, but that's my initial reaction.
>
>
>

I must of remembered it wrong David. I think I remember something about
trying not to have too many functions in a class...

On 2023-09-25, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> I must of remembered it wrong David. I think I remember something about
> trying not to have too many functions in a class...

If you have 100 functions in a module, such that a typical use of
the module has to use 95 of them, that's probably not very good.
(Even then, if there is a good argument that there is no other way it
can be done, while meeting some non-negotiable requirement, then it is
what it is.)

If they are various utilities that benefit certain usage scenarios
of the module, it may be acceptable to have a plethora of them.

Then we are just worried about code size in small systems: do we
have a linker that will remove individual unused function, or only
unused object files.

There is a case for having a detailed configuration system whereby the
integrator can select which functions are going to be present in the
image.

--
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 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.

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.
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.

Bart:
> Chris M. Thomasson:
> > Bart:
> >
> > > Huh? I didn't realise that was that controversial. I
> > > don't actually know how many functions I have per
> > > module, I've never counted!
> >
> > I think there is a complexity rule is MISRA that talks
> > about this...
>
> Are there are also rules about how many lines in a
> function, and how many modules in a program?

In fact, there are. There strictest ones I have ever met
with belong to Rebert Martin. In /Clean code/, he proposes
that a function have no more than 20 lines (and at most 3
parameters!), and a module no more than 200 lines.
Programmers tend to put limits on the complexity of the
lower-level (tactical?) program elements with which they
work, at the expense of higher-level (strategical?)
complexity describing modules/classes/interfaces.

In a 20-line function, I prefer the local variables declared
at the beginning, whereas in a 100-line function they are a
nuisance, but then there are likely other problems with the
function as well, such as trying to do too much, or
embracing more than one level of the conceptual task
hierarchy.

No, I cannot follow Martin's rules even for 80% of my code,
for various reasons. I cannot have a maximum of three
parameters without introducing ad-hoc stuctures to group
them /specificaly/ for that one call. Futhermore, if a
function returns an error flag, providing error details
(text, code, or perhaps a stack of text and code records) in
an output parameter, I am left with but one input parameter
and one output parameter (because the return value is in
use) -- clearly not enough. But that rules is possible in
popular OOP, because classes provide a /lot/ of additional
context to functions (one huge /self/ parameter), and errors
are frequently signalled out-or-bandwith, i.e. via
exceptions (no explicit error code and error info).

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.

> Further, there will be more complexity due to interactions
> or interfaces between functions and between modules being
> exposed, that could have been kept private.

I believe that with a good architecture this kind of higher-
level, strategical complexity is easier to manage, where I
agree with the mainstream consensus. The essence is exactly
to escalate tatcical low-level devilish complexity into the
cloulds, and there to deal with it with more elbow-room.

There are many measures of code/program/architecture
complexity. I wonder if anybody has tried to link with the
depth of nesting directly, although not via the primitive
max or mean statistics, but via something smarter, such as
median, or weighted average.

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.

I observe that technological progress provides a basis for a
sort of programming nazism, where all code is
unconditionally and obligatorily processed throught a
pretty- (aka ugly-) -printer before even a review, so that
the programmer cannot use any formatting whatsoever to
emphasize structure or better express his intent.

For an example, and the standard if-else-if-else... chain is
in fact a variant of a switch, and a switch has the
structure of a flat, two-dimensional table. That said, the
deeply nested format, often assumed for granted, is wrong (I
hope everyone reads this group in monospace font):

if( test_1 ) {
stat_1 } else {
if( test_2 ) {
stat_2 } else {
if( test_3 ) {
stat_3 } else {

and the correct format is flat and table-like:

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.

Coding standard 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.

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

I wrote:

> For an example, and the standard if-else-if-else... chain
> is in fact a variant of a switch, and a switch has the
> structure of a flat, two-dimensional table. That said,
> the deeply nested format, often assumed for granted, is
> wrong (I hope everyone reads this group in monospace
> font):
>
> if( test_1 ) {
> stat_1 } else {
> if( test_2 ) {
> stat_2 } else {
> if( test_3 ) {
> stat_3 } else {
>
> and the correct format is flat and table-like:
>
> 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.
>
> Coding standard rarely (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.

By the way, my restructuring in the latter format of a large
if-else- chain in DOSBox Staging did not pass code reivew,
the maintainer demanding that I revert it to the "correct"
form it had, which reminds me of another thought: that
enforced coding standards, especially in large projects with
a large and volatile body of programmers, serve to utilise
and organise the effort of so many sheep, who are a not
allowed to think for themselves, nor express themselves.
Junior programmers, fresh for the their university (or
whatever institution), find themselves thus shackled by
their first employer, and indoctrinated into mainstream
dogma at unawares, without a chance at reflection, thereby
losing the ability or independent judjement.

Thus, I know programmers who never gave thought to their
coding style. They simply process their code with the
standard formatting tool (with default settigns!) for their
language and don't care of the rest. This is encouraged, to
facilitate entry into the Nazi party: everbody else is doing
it, employees require it.

To avoid a grave misunderstanding -- the above does not
apply to anybody who has arrived at the mainstream consensus
by way of reason, rather than indoctrination.

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

On 26/09/2023 12:37, Anton Shepelev wrote:
> Bart:
>> Chris M. Thomasson:
>>> Bart:
>>>
>>>> Huh? I didn't realise that was that controversial. I
>>>> don't actually know how many functions I have per
>>>> module, I've never counted!
>>>
>>> I think there is a complexity rule is MISRA that talks
>>> about this...
>>
>> Are there are also rules about how many lines in a
>> function, and how many modules in a program?
>
> In fact, there are. There strictest ones I have ever met
> with belong to Rebert Martin. In /Clean code/, he proposes
> that a function have no more than 20 lines (and at most 3
> parameters!), and a module no more than 200 lines.
> Programmers tend to put limits on the complexity of the
> lower-level (tactical?) program elements with which they
> work, at the expense of higher-level (strategical?)
> complexity describing modules/classes/interfaces.
>
> In a 20-line function, I prefer the local variables declared
> at the beginning, whereas in a 100-line function they are a
> nuisance, but then there are likely other problems with the
> function as well, such as trying to do too much, or
> embracing more than one level of the conceptual task
> hierarchy.
>
> No, I cannot follow Martin's rules even for 80% of my code,
> for various reasons. I cannot have a maximum of three
> parameters without introducing ad-hoc stuctures to group
> them /specificaly/ for that one call. Futhermore, if a
> function returns an error flag, providing error details
> (text, code, or perhaps a stack of text and code records) in
> an output parameter, I am left with but one input parameter
> and one output parameter (because the return value is in
> use) -- clearly not enough. But that rules is possible in
> popular OOP, because classes provide a /lot/ of additional
> context to functions (one huge /self/ parameter), and errors
> are frequently signalled out-or-bandwith, i.e. via
> exceptions (no explicit error code and error info).
>
> Modern languages with multiple returns or tuples provide a
> partial solution,

To some arbitrarily limit? That would defeat the purpose of the rule:
you can't have more than 3 arguments, but any of those 3 can be a tuple
with 28 arguments!

Presumably that made-up rule was invented before named argument lists
came about. Then, functions with lots of parameters that have default
values, don't need to be called with all the arguments.

(Is there another equally silly rule about not having more than 3
members in a struct?)

>> Further, there will be more complexity due to interactions
>> or interfaces between functions and between modules being
>> exposed, that could have been kept private.
>
> I believe that with a good architecture this kind of higher-
> level, strategical complexity is easier to manage, where I
> agree with the mainstream consensus. The essence is exactly
> to escalate tatcical low-level devilish complexity into the
> cloulds, and there to deal with it with more elbow-room.
>
> There are many measures of code/program/architecture
> complexity.

C gives ample opporunity for complexity in what is supposed to be a
simple language:

* Burying things in layers of macros

* Having nested, conditional code blocks

So that is impossible to see, just by looking at source, exactly what is
being compiled. You need to start at the very top and look at every line
code and keep track of all the macros. But people aren't compilers.

So I think those rules about numbers of parameters, lines in a function
and so on, are pointless given the endless possibilities of C.

MY C code is very conservative, and would be very easy to compile,
understand, or translate, as I don't use conditional blocks and rarely
use macros. Most I come across isn't.

> I wonder if anybody has tried to link with the
> depth of nesting directly, although not via the primitive
> max or mean statistics, but via something smarter, such as
> median, or weighted average.
>
> 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.

Using hardware tabs on a paper teletype, which also limits you to 80
columns (or was it 72?) really was enforcing it mechanically.

> I observe that technological progress provides a basis for a
> sort of programming nazism, where all code is
> unconditionally and obligatorily processed throught a
> pretty- (aka ugly-) -printer before even a review, so that
> the programmer cannot use any formatting whatsoever to
> emphasize structure or better express his intent.
>
> For an example, and the standard if-else-if-else... chain is
> in fact a variant of a switch, and a switch has the
> structure of a flat, two-dimensional table. That said, the
> deeply nested format, often assumed for granted, is wrong (I
> hope everyone reads this group in monospace font):
>
> if( test_1 ) {
> stat_1 } else {
> if( test_2 ) {
> stat_2 } else {
> if( test_3 ) {
> stat_3 } else {
>

You haven't shown the full thing, which is more like this:

if( test_1 ) {
stat_1; } else {
if( test_2 ) {
stat_2; } else {
if( test_3 ) {
stat_3; } else {}}}

Those stat_* may or may not have braces. But the brace here: 'else {
if', if you were to strictly follow certain guidelines, requires the
correct sequence of closing } braces at the end.

Other languages (even C in its preprocessor!) use a special else-if
keyword to allow the chain without an arbitrary level of nesting and
therefore indents (a 100-way chain would need about 100 indents and 100
} near the end).

But C's {...} around single statements (like a nested 'if') is optional...

> and the correct format is flat and table-like:
>
> if( test_1 ) stat_1;
> else if( test_2 ) stat_2;
> else if( test_3 ) stat_3;

.... which allows you to write it like this, although usually without
that extra alignment. In theory there is still nesting, but no multiple
}s are needed at the end.

(Another way might be to start off with 'if (0);' then all actual blocks
will start with 'else if', except the optional final 'else' not shown in
your second example.)

> 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.

A trivial extension to the syntax could have taken care of it too. Like
'elsif', or I also created, elsewhere, this form, although I've never
used it:

case # usual control expression is blank
when test_1 then
stat_1a # no braces or begin-end needed
stat_1b
when test_2 then
stat_2
when test_1 then
stat_3
else
stat_4
end

This has the advantage, like my 'if(0)' idea, that any blocks can be
commented, uncommented, deleted, inserted and moved with greater
freedom, because the first condition+block does not have special syntax.

In article <20230926143726.8fd502c51264c4e127203da4@gmail.moc>,
Anton Shepelev <anton.txt@gmail.moc> wrote:
>Bart:
>>[snip]
>> Are there are also rules about how many lines in a
>> function, and how many modules in a program?
>
>In fact, there are. There strictest ones I have ever met
>with belong to Rebert Martin. In /Clean code/, he proposes
>that a function have no more than 20 lines (and at most 3
>parameters!), and a module no more than 200 lines.
>Programmers tend to put limits on the complexity of the
>lower-level (tactical?) program elements with which they
>work, at the expense of higher-level (strategical?)
>complexity describing modules/classes/interfaces.
>
>[snip]
>
>No, I cannot follow Martin's rules even for 80% of my code,
>for various reasons. I cannot have a maximum of three

Robert C Martin is, at best, a middling-quality programmer.
But more than that, the man is a blowhard and frankly no one
should take programming advice from him.

- Dan C.

Dan Cross:

> Robert C Martin is, at best, a middling-quality
> programmer.

Maybe he is, but how do you come to that conclusion?

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

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
Or, consider this commit:
https://github.com/unclebob/PDP8EmulatorIpad/commit/7a80391bdbc1b1d867079392e4bcf98fcad32014
in light of the timing of the above PR. Writing a bad rinkydink
little program is one thing; unacknowledged lifting from someone
else's work is another.)

One can look at other repositories and find similar examples of
poor quality code, most of which is small and/or demo-oriented,
anyway (he, like Allen Holub and other "Agile Influencers" has
very little production-quality code out in the open).

He also tends to opine on things he knows very little about.
For example, here he rails against static typing:
https://blog.cleancoder.com/uncle-bob/2019/06/08/TestsAndTypes.html
Most of this is simply nonsense, so much so that Shriram
Kirhsnamurthi called him out in a quote-tweet:
https://twitter.com/shriramkmurthi/status/1136411753590472707
(The context here is that a strong, static type system can
render many invalid programs simply unrepresentable, therefore
reducing the amount a programmer may have to test, since a
large swath of invalid programs can't be written in the first
place.)

- Dan C.

On 26/09/2023 13:37, Anton Shepelev wrote:
> Bart:
>> Chris M. Thomasson:
>>> Bart:
>>>
>>>> Huh? I didn't realise that was that controversial. I
>>>> don't actually know how many functions I have per
>>>> module, I've never counted!
>>>
>>> I think there is a complexity rule is MISRA that talks
>>> about this...
>>
>> Are there are also rules about how many lines in a
>> function, and how many modules in a program?
>
> In fact, there are. There strictest ones I have ever met
> with belong to Rebert Martin. In /Clean code/, he proposes
> that a function have no more than 20 lines (and at most 3
> parameters!), and a module no more than 200 lines.
> Programmers tend to put limits on the complexity of the
> lower-level (tactical?) program elements with which they
> work, at the expense of higher-level (strategical?)
> complexity describing modules/classes/interfaces.
>
> In a 20-line function, I prefer the local variables declared
> at the beginning, whereas in a 100-line function they are a
> nuisance, but then there are likely other problems with the
> function as well, such as trying to do too much, or
> embracing more than one level of the conceptual task
> hierarchy.
>
> No, I cannot follow Martin's rules even for 80% of my code,
> for various reasons. I cannot have a maximum of three
> parameters without introducing ad-hoc stuctures to group
> them /specificaly/ for that one call. Futhermore, if a
> function returns an error flag, providing error details
> (text, code, or perhaps a stack of text and code records) in
> an output parameter, I am left with but one input parameter
> and one output parameter (because the return value is in
> use) -- clearly not enough. But that rules is possible in
> popular OOP, because classes provide a /lot/ of additional
> context to functions (one huge /self/ parameter), and errors
> are frequently signalled out-or-bandwith, i.e. via
> exceptions (no explicit error code and error info).
>
> 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? It is maybe not quite as
convenient in C as in languages supporting multiple return values, but
it is certainly possible.

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

>> Further, there will be more complexity due to interactions
>> or interfaces between functions and between modules being
>> exposed, that could have been kept private.
>
> I believe that with a good architecture this kind of higher-
> level, strategical complexity is easier to manage, where I
> agree with the mainstream consensus. The essence is exactly
> to escalate tatcical low-level devilish complexity into the
> cloulds, and there to deal with it with more elbow-room.
>
> There are many measures of code/program/architecture
> complexity. I wonder if anybody has tried to link with the
> depth of nesting directly, although not via the primitive
> max or mean statistics, but via something smarter, such as
> median, or weighted average.
>
> 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.

>
> I observe that technological progress provides a basis for a
> sort of programming nazism, where all code is
> unconditionally and obligatorily processed throught a
> pretty- (aka ugly-) -printer before even a review, so that
> the programmer cannot use any formatting whatsoever to
> emphasize structure or better express his intent.
>
> 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.

> structure of a flat, two-dimensional table. That said, the
> deeply nested format, often assumed for granted, is wrong (I
> hope everyone reads this group in monospace font):
>
> 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.

>
> and the correct format is flat and table-like:
>
> 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.

> 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.

>
> Coding standard 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.

On 26/09/2023 13:57, Anton Shepelev wrote:
> I wrote:
>
>> For an example, and the standard if-else-if-else... chain
>> is in fact a variant of a switch, and a switch has the
>> structure of a flat, two-dimensional table. That said,
>> the deeply nested format, often assumed for granted, is
>> wrong (I hope everyone reads this group in monospace
>> font):
>>
>> if( test_1 ) {
>> stat_1 } else {
>> if( test_2 ) {
>> stat_2 } else {
>> if( test_3 ) {
>> stat_3 } else {
>>
>> and the correct format is flat and table-like:
>>
>> 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.
>>
>> Coding standard rarely (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.
>
> By the way, my restructuring in the latter format of a large
> if-else- chain in DOSBox Staging did not pass code reivew,
> the maintainer demanding that I revert it to the "correct"
> form it had, which reminds me of another thought: that
> enforced coding standards, especially in large projects with
> a large and volatile body of programmers, serve to utilise
> and organise the effort of so many sheep, who are a not
> allowed to think for themselves, nor express themselves.

Sorry, but you are wrong here.

Consistent style is very important in large projects, greatly reducing
the effort needed for different programmers to understand and work on
different bits of code. Consistency is usually more important than the
details of the style. Maverick styles like yours have no place in group
efforts.

> Junior programmers, fresh for the their university (or
> whatever institution), find themselves thus shackled by
> their first employer, and indoctrinated into mainstream
> dogma at unawares, without a chance at reflection, thereby
> losing the ability or independent judjement.
>

You are the one who is using a style that, at best, might have been of
interest decades ago. Perhaps you were not influenced by mainstream
coding styles, but that's nothing to be proud of - other people know
better than you, but you have not learned from them. Looking at other
styles and taking the best from them (where "best" depends on many
factors, and is not absolute) is not "indoctrination", it is just
learning from other people's experiences.

> Thus, I know programmers who never gave thought to their
> coding style. They simply process their code with the
> standard formatting tool (with default settigns!) for their
> language and don't care of the rest. This is encouraged, to
> facilitate entry into the Nazi party: everbody else is doing
> it, employees require it.
>

If you don't have particular reason to pick a different style, then
common standards are usually a very good starting point. Maybe the
programmer using them hasn't thought them through in detail - but
/someone/ has.

You /have/ thought about your coding style. That does not make it good.
You just think it is good because you have used it for decades.

> To avoid a grave misunderstanding -- the above does not
> apply to anybody who has arrived at the mainstream consensus
> by way of reason, rather than indoctrination.
>

Some people have this bizarre notion that following common standards, or
listening to mainstream opinions, or - heaven forbid! - paying attention
to established and qualified experts is somehow "indoctrination". Did
it ever occur to you that sometimes when lots of people agree on
something, or work the same way, it is perhaps because it is a good idea?

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.

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.

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.

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.

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. :)

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 */;

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

--
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.