src/ceph/CodingStyle

   1 Ceph Coding style
   2 -----------------
   3
   4 Coding style is most important for new code and (to a lesser extent)
   5 revised code.  It is not worth the churn to simply reformat old code.
   6
   7 C code
   8 ------
   9
  10 For C code, we conform by the Linux kernel coding standards:
  11
  12     https://www.kernel.org/doc/Documentation/CodingStyle
  13
  14
  15 C++ code
  16 --------
  17
  18 For C++ code, things are a bit more complex.  As a baseline, we use Google's
  19 coding guide:
  20
  21     https://google.github.io/styleguide/cppguide.html
  22
  23
  24 As an addendum to the above, we add the following guidelines, organized
  25 by section.
  26
  27 * Naming > Type Names:
  28
  29     Google uses CamelCaps for all type names.  We use two naming schemes:
  30
  31     - for naked structs (simple data containers), lower case with _d
  32       suffix ('d' for data).  Not _t, because that means typdef.
  33
  34         struct my_type_d {
  35           int a, b;
  36           my_type_d() : a(0), b(0) {}
  37         };
  38
  39     - for full-blown classes, CamelCaps, private: section, accessors,
  40       probably not copyable, etc.
  41
  42 * Naming > Variable Names:
  43
  44    Google uses _ suffix for class members.  That's ugly.  We'll use
  45    a m_ prefix, like so:
  46
  47         class Foo {
  48          public:
  49           int get_foo() const { return m_foo; }
  50           void set_foo(int foo) { m_foo = foo; }
  51
  52          private:
  53           int m_foo;
  54         };
  55
  56 * Naming > Constant Names:
  57
  58    Google uses kSomeThing for constants.  We prefer SOME_THING.
  59
  60 * Naming > Function Names:
  61
  62    Google uses CamelCaps.  We use_function_names_with_underscores().
  63
  64    Accessors are the same, {get,set}_field().
  65
  66 * Naming > Enumerator Names:
  67
  68    Name them like constants, as above (SOME_THING).
  69
  70 * Comments > File Comments:
  71
  72    Don't sweat it, unless the license varies from that of the project
  73    (LGPL2) or the code origin isn't reflected by the git history.
  74
  75 * Formatting > Tabs:
  76   Indent width is two spaces.  When runs of 8 spaces can be compressed
  77   to a single tab character, do so. The standard Emacs/Vim settings
  78   header is:
  79
  80 // -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*-
  81 // vim: ts=8 sw=2 smarttab
  82
  83 * Formatting > Conditionals:
  84
  85    - No spaces inside conditionals please, e.g.
  86
  87         if (foo) {   // okay
  88
  89         if ( foo ) { // no
  90
  91    - Always use newline following if:
  92
  93         if (foo)
  94           bar;         // okay, but discouraged...
  95
  96         if (foo) {
  97           bar;         // this is better!
  98         }
  99
 100         if (foo) bar;  // no, usually harder to parse visually
 101
 102
 103
 104
 105 The following guidelines have not been followed in the legacy code,
 106 but are worth mentioning and should be followed strictly for new code:
 107
 108 * Header Files > Function Parameter Ordering:
 109
 110     Inputs, then outputs.
 111
 112 * Classes > Explicit Constructors:
 113
 114     You should normally mark constructors explicit to avoid getting silent
 115 type conversions.
 116
 117 * Classes > Copy Constructors:
 118
 119     - Use defaults for basic struct-style data objects.
 120
 121     - Most other classes should DISALLOW_COPY_AND_ASSIGN.
 122
 123     - In rare cases we can define a proper copy constructor and operator=.
 124
 125 * Other C++ Features > Reference Arguments:
 126
 127     Only use const references.  Use pointers for output arguments.
 128
 129 * Other C++ Features > Avoid Default Arguments:
 130
 131     They obscure the interface.