On Wed, Jul 13, 2011 at 11:08 AM, Colin McCabe <cmccabe@xxxxxxxxxxxxxx> wrote:
> On Wed, Jul 13, 2011 at 11:04 AM, Yehuda Sadeh Weinraub
> <yehudasa@xxxxxxxxx> wrote:
>> On Wed, Jul 13, 2011 at 10:59 AM, Samuel Just <samuelj@xxxxxxxxxxxxxxx> wrote:
>>> On 07/13/2011 10:52 AM, Yehuda Sadeh Weinraub wrote:
>>>>>
>>>>> * Naming> Type Names:
>>>>>
>>>>> Google uses CamelCaps for all type names. We use two naming schemes:
>>>>>
>>>>> - for structs (simple data containers), lower case with _t suffix:
>>>>> struct my_type_t {
>>>>> int a, b;
>>>>> my_type_t() : a(0), b(0) {}
>>>>> };
>>>>
>>>> I'd rather have the struct naming without the _t suffix (as with the C
>>>> code), and typedef to add _t, e.g.:
>>>>
>>>> typedef struct my_type {
>>>> ...
>>>> } my_type_t;
>>>>
>>> What is the advantage of the typedef?
>>
>> Being consistent. That's what we do in C. The _t suffix denotes a
>> typedef, so it should be defined as one. We also mix C and C++ from
>> time to time (e.g., we have code that is common to both userspace side
>> and kernel side and/or links with other projects like qemu), so
>> keeping the same notation is crucial.
>>
>
> Actually, using typedef that way is *inconsistent*, since we claim to
> follow the kernel coding style document. And this is what it has to
> say about that:
>
>> Please don't use things like "vps_t".
>>
>> It's a _mistake_ to use typedef for structures and pointers. When you see a
>>
>> vps_t a;
>>
>> in the source, what does it mean?
>>
>> In contrast, if it says
>>
>> struct virtual_container *a;
>>
>> you can actually tell what "a" is.
Whether to typedef or not is a different issue. If you want a _t
suffix, use typedef.
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
