X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=src%2Fceph%2FCodingStyle;fp=src%2Fceph%2FCodingStyle;h=870c0ce5d39dfb2295d34a607d7b155c5a094e3c;hb=812ff6ca9fcd3e629e49d4328905f33eee8ca3f5;hp=0000000000000000000000000000000000000000;hpb=15280273faafb77777eab341909a3f495cf248d9;p=stor4nfv.git

diff --git a/src/ceph/CodingStyle b/src/ceph/CodingStyle
new file mode 100644
index 0000000..870c0ce
--- /dev/null
+++ b/src/ceph/CodingStyle
@@ -0,0 +1,131 @@
+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:
+
+    https://www.kernel.org/doc/Documentation/CodingStyle
+
+
+C++ code
+--------
+
+For C++ code, things are a bit more complex.  As a baseline, we use Google's
+coding guide:
+
+    https://google.github.io/styleguide/cppguide.html
+
+
+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 > Tabs:
+  Indent width is two spaces.  When runs of 8 spaces can be compressed
+  to a single tab character, do so. The standard Emacs/Vim settings
+  header is:
+
+// -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*-
+// vim: ts=8 sw=2 smarttab
+
+* 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.