Keith said:
struct DIR *opendir(char *dirname);
struct Dirent *readdir(struct DIR *dfd);
void closedir(struct DIR *dfd);
IMHO, it isn't. Ease of typing is a trivial concern; code will be
read more often than it's written. The language gives us an easy way
to make it obvious that a given type is a struct; we might as well use
it rather than hiding it behind a typedef (unless, of course, there's
a good reason to hide it).
I agree about the typing. When I was originally composing my post I
hesitated a bit before including that comment, but decided to leave it
in for completeness.
For the other one, it's almost a matter of taste, and possibly
background. My first programming language was Pascal (I don't count
BASIC ;-) ), where once a type is created it's indistinguishable from
the built-in ones.
Another argument may be that, knowing something is a struct doesn't
necessarily save you looking for it's definition (what are the members,
apart from the ones you see referenced in front of you?). You'd
essentially have to do the same for all typedefs with non-obvious names
(and even those are always suspect).
Yet another is: if you're creating a new type -- spell it out. It's
marginally easier, and possibly less error-prone to grep for typedefs,
than for typedefs and structs, and then have to sort out which are
defining new types, and which are not.
(Yes, I'm disagreeing with K&R, which means I'm running a considerable
risk of being wrong. It's a risk I'm willing to take.)
Nothing wrong with either. ;-)
In the end, I believe this is a matter to be decided when writing a
coding standard for any particular shop, and then be done with it.
Cheers
Vladimir