On Mon, Feb 17, 2025 at 09:24:11PM +0100, Günther Noack wrote:
> Hi!
Hi!
> > +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).
> > +
> > +Description
> > + Indentation
> > + Use 4 spaces. Ideally, tabs would be preferred; however, they
> > + cause 5 spaces in manual pages, which is weird, so we use 4
> > + spaces.
> > +
> > + if (foo)
> > + bar();
> > +
> > + Indent preprocessor directives after the hash by 1 space.
> > +
> > + #ifndef FOO
> > + # define FOO
> > + #endif
> > +
> > + 'case' is not indented within a 'switch'.
> > +
> > + switch (x) {
> > + case 1:
> > + foo();
> > + break;
> > + default:
> > + break;
> > + }
> > +
> > + Line length
> > + Lines should not be longer than 80 columns.
>
> I assume that this is referring to a column limit on the fully
> rendered man page, including surrounding indentation?
It applies at several levels:
- The source code cannot go past column 80.
- The rendered page cannot go past column 80.
80 is a hard limit in every way possible.
> > + Except that if they
> > + contain string literals, they can be longer; don't break
> > + user-visible string literals.
> > +
> > + When breaking a function prototype, start the continuation line
> > + with 4 spaces.
>
> When we break parameter lists in function prototypes, do we need to
> break them in function definitions the same?
Yes. With the only difference that the return type goes in a line of
its own in the definition, but goes in the same line in the declaration.
> I'm asking because it
> might make the indentation confusing when it's next to a function body
> with the same indentation. For instance:
>
> void foobar(char *bananas, int oranges, float pineapples,
> int cucumbers) {
The opening brace goes in a line of its own. It should be:
void foobar(char *bananas, int oranges, float pineapples,
int cucumbers);
void
foobar(char *bananas, int oranges, float pineapples,
int cucumbers)
{
}
> int gherkins;
> int potatoes;
>
> /* actual code starts here */
> }
>
> Now the last parameter and the local variables have the same
> indentation and can get confused more easily.
The rule for braces is K&R, which places the opening brace of a function
in a line of its own (unlike most other braces).
When a conditional is split across several lines, I also override K&R by
moving the brace to an empty line to avoid precisely that:
if (foooooooooooooooooooooooooo
|| baaaaaaaaaaaaaaaaaaaaaaaaaar)
{
baz();
}
> > +
> > + When breaking a function call, align at the opening parenthesis.
> > +
> > + Braces and spaces
> > + Use K&R style for braces. But if the controlling expression of
> > + an if/for/while is broken, the opening brace goes on a line of
> > + its own.
> > +
> > + if (foo)
> > + bar();
> > +
> > + if (foooooooooooooooooooooooooo
> > + || baaaaaaaaaaaaaaaaaaaaaaaaaar)
> > + {
> > + baz();
> > + }
> > +
> > + Treat sizeof() and similar operators as functions, not keywords.
> > + Use a space after keywords, but not after functions.
> > +
> > + Use a space to separate binary and ternary operators (except
> > + `.` and `->`), but not to separate unary operators.
> > +
> > + Use a space between a cast and the expression it converts.
> > +
> > + Naming
> > + Use short names. Long names should be an exception, and
> > + indicate that something probably isn't well designed.
> > +
> > + Functions
> > + Functions should be short and sweet.
> > +
> > + All functions should have prototypes.
>
> Like this?
>
> int foobar(int a, int b);
>
> int foobar(int a, int b) {
> return a + b;
> }
>
> I don't understand what this duplication would be good for.
> Or I am misunderstanding what you meant here. :)
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.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
