[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Code style and languages in the C family (was: REVISED groff 1.24.0
From: |
Larry McVoy |
Subject: |
Re: Code style and languages in the C family (was: REVISED groff 1.24.0 readiness status, and release notes) |
Date: |
Mon, 18 Nov 2024 17:57:22 -0800 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Mon, Nov 18, 2024 at 07:39:09PM -0600, G. Branden Robinson wrote:
> At 2024-11-19T01:47:33+0100, onf wrote:
> > On Tue Nov 19, 2024 at 12:37 AM CET, G. Branden Robinson wrote:
> > > At 2024-11-18T21:43:24+0100, onf wrote:
> > > > [...]
> > > > Just a small nitpick, but you should probably do s/(warning) /\1/.
> > >
> > > Yes, that was a code style goof. Thanks! Fixed.
> >
> > Hopefully the way I suggested...
>
> Yes. Clark's coding style is not the one from the GNU Coding Standards,
> with the weird brace indentation.
>
> Personally, I have a strong distaste for jamming parentheses up against
> control structure keywords, like `if(` or `switch(`, though I know some
> disciples of old-school Bell Labs code will cling to it unto death.
Just weighing in with my style because I'm waiting for my dinner to cook...
I like
void *
malloc(size_t size)
{
}
because I can grep for "^malloc(" and find the function definition rather
than calls to it.
I'm a former Linux kernel guy, briefly, and I don't care for their style.
I do
#define unless(x) if (!(x))
if (something) something_else;
if (somemorethings) {
one;
two;
or_more;
} else if (whatever) {
whatever;
} else {
else;
}
I tend to write functions sort of like so:
int
somefunc(args...)
{
char* a = 0;
int* b = 0;
type* c = 0;
unless (a = malloc(something)) goto err;
...
unless (b = malloc(something * sizeof(int) goto err;
...
unless (c = malloc(something * sizeof(type) goto err;
// bunch of code that does stuff with a, b, c
return (success);
err: if (a) free(a);
if (b) free(b);
if (c) free(c);
return (error);
}
Dinner is ready, I'm out.
- Re: groff 1.24.0 readiness status, and release notes, (continued)
- Re: groff 1.24.0 readiness status, and release notes, Deri, 2024/11/16
- REVISED groff 1.24.0 readiness status, and release notes, G. Branden Robinson, 2024/11/16
- Re: REVISED groff 1.24.0 readiness status, and release notes, Deri, 2024/11/17
- Re: REVISED groff 1.24.0 readiness status, and release notes, G. Branden Robinson, 2024/11/17
- Re: REVISED groff 1.24.0 readiness status, and release notes, Deri, 2024/11/18
- Re: REVISED groff 1.24.0 readiness status, and release notes, G. Branden Robinson, 2024/11/18
- Re: REVISED groff 1.24.0 readiness status, and release notes, onf, 2024/11/18
- Re: REVISED groff 1.24.0 readiness status, and release notes, G. Branden Robinson, 2024/11/18
- Re: REVISED groff 1.24.0 readiness status, and release notes, onf, 2024/11/18
- Code style and languages in the C family (was: REVISED groff 1.24.0 readiness status, and release notes), G. Branden Robinson, 2024/11/18
- Re: Code style and languages in the C family (was: REVISED groff 1.24.0 readiness status, and release notes),
Larry McVoy <=
- Re: Code style and languages in the C family (was: REVISED groff 1.24.0 readiness status, and release notes), onf, 2024/11/18
- Re: Code style and languages in the C family (was: REVISED groff 1.24.0 readiness status, and release notes), onf, 2024/11/18
Re: groff 1.24.0 readiness status, and release notes, G. Branden Robinson, 2024/11/16