On Wed, Nov 19, 2014 at 07:58:28PM +0100, k...@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
