From: Thomas Martitz <kugel_at_rockbox.org>
Date: Fri, 29 Nov 2013 09:27:33 +0100

Hello,

as you know we have a "no typedef rule" in our guidelines. However there
are a few problems with it when applied to integral types:

* Portability is reduced, for example we use unsigned for thread ids but
pthread uses unsigned long (I have some work where we can use pthreads,
at least in parts). This could be handled better with a typedef.
* Readability is reduced, for example we use long for our tick. IMO
readability/expressiveness would be improved by refering to a "tick_t"
instead of ordinary long.
* Type checking is prevented, for example gcc could do better type
checking with proper typedefs. It's easy to think "I can use int instead
of long" when the global tick really needs to be a long.

The Linux kernel coding guidelines have summarized the issues even
better: https://www.kernel.org/doc/Documentation/CodingStyle (chapter 5).

Therefore I propose that we relax the typedef rule and allow typedefs
for integral types (only) when reasonable. This would basically be
adopting the Linux kernel guideline w.r.t. to typedefs, except they
allow typedefs for "totally opaque objects (where the typedef is
actively used to _hide_ what the object is)."


In essence:
  - No typedef for structs and unions. These types help with the
aforementioned problems by themselves.
  - No typedef for pointers. Hiding a pointer between some type remains
silly.
  - No typedef for trivial ints, like normal counters (except tick) or
something like that.
  - Allow typedefs where reasonable, i.e. where it helps enforcing a
specific type, improves readability and portability.
  - Allow typedefs for void, as to give "void *" a more telling type.

I'd like to trust our developers to weigh up what's reasonable.

Best regards.
Received on 2013-11-29