I regularly coach advanced C to the great engineers at Tandberg in Oslo. One of the topics we've discussed is typedef style. For example
- not using typedefs (Linux kernel style) like this
struct wibble;
void wibble_this(struct wibble *);
void wibble_that(struct wibble *);
- or with typedefs, like this
struct wibble;
typedef struct wibble wibble;
void wibble_this(wibble *);
void wibble_that(wibble *);
This matters because typedefs are not idempotent in C, which is to say you can't write this
typedef struct wibble wibble;
...
typedef struct wibble wibble; // non-conforming duplicate
A C file has its #includes and these #includes will have their own #includes, ad infinitum. It can be tricky knowing whether a type has already been typedef'd or not, and hence whether the C file has to declare its own typedef or not (for example, when forward declaring the type). However, there is a style that neatly avoids this problem
- in header files don't typedef
// wibble.h
struct wibble;
void wibble_this(struct wibble *);
void wibble_that(struct wibble *);
- in source files do typedef
// use.c
#include "wibble.h"
typedef struct wibble wibble;
void eg1(wibble * w)
{
...
}
void eg2(void)
{
wibble * w = ...
...
}
This is somewhat similar to the C++ rule that header files always use explicit :: qualification.
My friend Kevlin Henney commented that the idea is also resembles using typedef's in the private section of a C++ class which is a nice observation.
I haven't tried this on a large codebase. At the moment it's just an idea. Caveat emptor.
is the title of a great book by Patrick Lencioni. The subtitle is "a leadership fable" and pages 1-185 form a story of how a new CEO starts to turns around a dysfunctional group of individual high achievers who are not pulling together as a team. Each "chapter" is rarely more than four pages long and the story moves along at a brisk and enjoyable pace.
