Am 02.12.2013 11:35, schrieb Björn Stenberg:
Thomas Martitz wrote:
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,
There are times when typedefs are useful, but they are in fact exceptions. I
think rather than say we now allow typedefs via some complex set of rules, it
is better to treat each typedef as an exception and document in a comment next
to the declaration why this typedef is granted an exception. These exceptions
can then be explained using the linux kernel guidelines.
I disagree. Typedefs are useful not only in rare exceptional cases. They
provide advantages over plain int/long/etc (such improved expressiveness
for expected parameters, type safety and portability). I agree that they
hurt if applied to unions and structs because both provide the
advantages already by themselves. Integral types, however, are
interchangeable. This is error prone and a plain "int" doesn't give any
information about the expectations for parameters.
For example the sleep function. It accepts an int paramter (named
ticks). The type doesn't carry any information itself, it's not
immediately clear that ticks are special, e.g. derived somehow from
current_tick (which is a long!) or calculated with HZ. Were it named
tick_t it would be much easier to understand that it's a special kind of
int, and that it relates to current_tick and other related kernel
functions that take ticks.
I don't ask to use typedefs excessively, they should be used where it
makes sense only. But I don't want to ask for an exception every time,
especially not if the reasons to grant the exception are always the
same. If we are going to point to the Linux kernel guidelines to explain
the exception we can just as well adopt the rules into our guidelines
(perhaps with a note "use sparingly" or so).
I'd like to trust our developers to weigh up what's reasonable.
That is a slippery assumption. The problem is not "our developers", i.e. those already experienced
with Rockbox and know our history and rules. The problem is that "reasonable" has as many
definitions as there are people, and even the most horribly obfuscating, code-hiding, typedef-abusing
devlopers consider their approach "reasonable".
There are many more ways to achieve these without typedefs. Plus, I
don't think disallowing typedefs makes obfuscated and hidden code any
better. It such code gets in it's not typdef's fault, it's the review
process.
It is therefore important to be clear up front about what is accepted and not,
to avoid people writing large patches in an unacceptable code style.
Exactly! However, saying "generally no typedefs, but we have a many many
exceptions" is far from cleared up. Therefore I want to clear define
rules under which typedefs can be accepted. Then we don't need to have
exceptions, but can follow written-down rules.
Best regards.
