I've always wondered if there are any naming convetions as when to use ALLCAPS for a type and when to append _t
(and when to not use anything?). I know back in the days K&R published all kinds of documents about how to use C, but I couldn't find anything about this.
Among the C standard library types, _t
seem prettys dominant
time_t
clock_t
uint32_t
size_t
sig_atomic_t
...
, as opposed to FILE
, va_list
or struct tm
. Are there actually rules to this or is it completely arbitrary? Microsoft always uses typenames in ALLCAPS in their Windows API, which at least seems more consistent than the C library, frankly...
Classic C doesn't use camel-case; I've written code in camel-case in C, and it looks weird (so I don't do it like that any more). That said, it isn't wrong - and consistency is more important than which convention is used.
The _t usually wraps an opaque type definition. The requirement that additional types defined in this section end in "_t" was prompted by the problem of name space pollution. It is difficult to define a type (where that type is not one defined by POSIX.
Function, typedef, and variable names, as well as struct, union, and enum tag names should be in lower case.
Actually according to the POSIX standard, all type names ending in _t are reserved, as defined here:
Names that end with ‘_t’ are reserved for additional type names.
I would strive to minimize your use of typedef
. Use the struct
keyword for structures and only use typedef when you're either (a) defining an opaque type that might be implemented as anything, or (b) defining an alias for an arithmetic type you might want to change in the future or in different configurations (for example if you want to be able to choose float
or double
).
In any case, don't use ALL CAPS because it's hideously ugly, and don't use _t
because it's reserved by POSIX. That probably doesn't matter if you prefix your type names appropriately, but then the _t
on the end is just unnecessary ugliness and gratuitous nonportability. Just prefixing them like this should be fine: foo_scalar
(where foo
is the name of your library/module).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With