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.
If we do decide we have a burning desire to surround every struct with
a typedef (yuck!) we should at least note the inconsistency in the
CodingStyle document, the same way we note the other Ceph
specific-stuff.
regards,
Colin
--
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
