|
Rockbox mail archiveSubject: Re: Typedef ruleRe: Typedef rule
From: Thomas Martitz <kugel_at_rockbox.org>
Date: Mon, 02 Dec 2013 12:01:24 +0100 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. Received on 2013-12-02 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |