Hi Branden,

On Mon, Feb 17, 2025 at 04:35:37PM -0600, G. Branden Robinson wrote:

At 2025-02-17T23:16:59+0100, Alejandro Colomar wrote:

quoted

On Mon, Feb 17, 2025 at 09:24:11PM +0100, Günther Noack wrote:

quoted

quoted

+Name
+       style/c - C coding style

"...for code examples in man pages"?

I didn't specify, because it also applies to programs written in commit
messages (for example to prove that a patch is correct).  It applies to
every C program that I have to look at as maintainer of this project
(and actually, of any project that I comaintain too).

Maybe you need a name for this class/category.

"Colomar C coding style guide"?

Well, I guess being a file within our repository makes it explicit
enough that it applies at least to this project in its entirety.  That
is also applies to my other things, is coincidence.  :)

I'll avoid giving it a name, for now.

quoted

The definitions go all after main().  The prototypes go all before
main().  The benefit is that you can get an overview of what is
defined without having to look at the implementation.

My understanding is that function prototypes were added to the C
language to permit type-checking of function call arguments (and return
values) _across_ translation units--specifically.  So if a function is
static, or has no callers outside of its translation unit,[1] the
compiler can be expected to exercise whatever type-checking facilities
it has within that translation unit.  (I admit not knowing whether the
pre-ANSI Ritchie compiler or pcc were this careful.  I'll brace myself.)

Yep, their main reason to exist is type safety across TUs.  However,
that is useless in this project, because example programs are a single
TU most of the time.

However, they're still useful as an "index" of the program source code.
You can have a look at the list of prototypes, and that gives you an
idea of what is implemented below.

Regards,
Branden

[1] ...in which case the correct thing to do is _declare it static_, but
    hey, this is C, man, we're "terse".  More modern languages like Go
    and Rust have started to recognize that having symbols be public
    and/or mutable by default are worse choices for modularity and
    concurrency.  Even Ada was not quite this careful.

Even for functions internal to a TU, I do always provide prototypes for
them in my code.  It helps see what's in a .c file by looking at the
"index" at the top.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>