Following are my remarks to the new coding style document: On Wed, Jul 13, 2011 at 10:34 AM, Yehuda Sadeh Weinraub <yehudasa@xxxxxxxxx> wrote: > Ceph Coding style > ----------------- > > Coding style is most important for new code and (to a lesser extent) > revised code. It is not worth the churn to simply reformat old code. > > C code > ------ > > For C code, we conform by the Linux kernel coding standards: > > http://lxr.linux.no/linux/Documentation/CodingStyle > > > C++ code > -------- > > For C++ code, things are a bit more complex. As a baseline, we use Google's > coding guide: > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > > > As an addendum to the above, we add the following guidelines, organized > by section. > > * 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; > - for regular classes, CamelCaps, private: section, etc. > > * Naming > Variable Names: > > Google uses _ suffix for class members. We haven't up until now. Should we? No. > > * Naming > Constant Names: > > Google uses kSomeThing for constants. We prefere SOME_THING. > > * Naming > Function Names: > > Google uses CamelCaps. We use_function_names_with_underscores(). > > Accessors are the same, {get,set}_field(). > > * Naming > Enumerator Names: > > Name them like constants, as above (SOME_THING). > > * Comments > File Comments: > > Don't sweat it, unless the license varies from that of the project (LGPL2) or > the code origin isn't reflected by the git history. > > * Formatting > Conditionals: > > - No spaces inside conditionals please, e.g. > > if (foo) { // okay > > if ( foo ) { // no > > - Always use newline following if: > > if (foo) > bar; // okay > > if (foo) bar; // no, usually hardler to visually parse > > > > > The following guidelines have not been followed in the legacy code, > but are worth mentioning and should be followed strictly for new code: > > * Header Files > Function Parameter Ordering: > > Inputs, then outputs. I generally agree, just that there's a class of strcpy like functions that put the destination first. This usually makes sense when you have multiple functions that do similar things with varied input parameters: char *strcpy(char *dest, const char *src); char *strncpy(char *dest, const char *src, size_t n); So in both cases, dest and src are the first and second parameters, which looks more consistent. And there's also the case of using default values, which usually (though not always) applies to the input parameters. Enforcing strict input before output ordering wouldn't work there. > > * Classes > Explicit Constructors: > > You should normally mark constructors explicit to avoid getting silent > type conversions. > 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
