Re: [dev] [sbase] style

From: Markus Wichmann <nullplan_AT_gmx.net>
Date: Thu, 20 Nov 2014 06:31:51 +0100

On Wed, Nov 19, 2014 at 07:58:28PM +0100, k0ga_AT_shike2.com wrote:
> For long time I followed the rule of kernel style of not using typedef
> ever, but I changed it to the rule of using typedef only with structs
> and capital letter, and I can say that this last is far better; You
> get more readable function definitions:
>
> funcion(struct Term *term1, struct Term *term2)
>
> becomes
>
> function(Term *term1, Term *term2)
>
>
> Regards,

How's that more readable? I do agree that function pointer typedefs make
stuff easier to read, because when I read the definition

void (*signal(int, void(*)(int)))(int);

I start to think that I may have stumbled into a LISP source code by
accident. Whereas

typedef void (*sighandler)(int);
sighandler signal(int, sighandler);

But regarding the typedefs for structs: C has only a few namespace
features, so lets not dismantle the probably most used one, alright?
"struct stat" can be something different from "stat()"! I like that
namespace thing so much I even use it in C++ (declaring objects with
"class foo object;"). Not that I use C++ all that often, but, you know,
professional obligations and shit.

In your above example in the first definition it is clear that Term is a
struct to everyone. All I know from the second definition is that I have
to look up what a Term is, because for all I can see it might be
typedef'd to a pointer type, or a union, or an array of whatever. True,
that might not be necessary all that often, but with your first line it
becomes completely unnecessary.

Oh, and typedefing struct pointers is just evil. For instance, when you
declare

struct foo;
typedef struct foo *PST_FOO;
function(const PST_FOO);

then what have you qualified as const there? (BTW, my workplace wants me
to prefix struct types with "st" or "ST", but doesn't want me to use tag
names. That's a stupid thing if I ever heard one, but oh well, we deal
with the hands we're played, I guess.)

Ciao,
Markus
Received on Thu Nov 20 2014 - 06:31:51 CET