ceph/CodingStyle

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 naked structs (simple data containers), lower case with _d
      suffix ('d' for data).  Not _t, because that means typdef.

        struct my_type_d {
          int a, b;
          my_type_d() : a(0), b(0) {}
        };

    - for full-blown classes, CamelCaps, private: section, accessors,
      probably not copyable, etc.

* Naming > Variable Names:

   Google uses _ suffix for class members.  That's ugly.  We'll use
   a m_ prefix, like so:

        class Foo {
	 public:
          int get_foo() const { return m_foo; }
          void set_foo(int foo) { m_foo = foo; }

         private:
          int m_foo;
   	};
   
* Naming > Constant Names:

   Google uses kSomeThing for constants.  We prefer 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, but discouraged...

        if (foo) {
          bar;         // this is better!
        }

        if (foo) bar;  // no, usually harder to parse visually




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.

* Classes > Explicit Constructors:

    You should normally mark constructors explicit to avoid getting silent
type conversions.

* Classes > Copy Constructors:

    - Use defaults for basic struct-style data objects.

    - Most other classes should DISALLOW_COPY_AND_ASSIGN.

    - In rare cases we can define a proper copy constructor and operator=.

* Other C++ Features > Reference Arguments:

    Only use const references.  Use pointers for output arguments.

* Other C++ Features > Avoid Default Arguments:

    They obscure the interface.