summaryrefslogtreecommitdiffstats
path: root/src/ceph/CodingStyle
diff options
context:
space:
mode:
authorQiaowei Ren <qiaowei.ren@intel.com>2018-01-04 13:43:33 +0800
committerQiaowei Ren <qiaowei.ren@intel.com>2018-01-05 11:59:39 +0800
commit812ff6ca9fcd3e629e49d4328905f33eee8ca3f5 (patch)
tree04ece7b4da00d9d2f98093774594f4057ae561d4 /src/ceph/CodingStyle
parent15280273faafb77777eab341909a3f495cf248d9 (diff)
initial code repo
This patch creates initial code repo. For ceph, luminous stable release will be used for base code, and next changes and optimization for ceph will be added to it. For opensds, currently any changes can be upstreamed into original opensds repo (https://github.com/opensds/opensds), and so stor4nfv will directly clone opensds code to deploy stor4nfv environment. And the scripts for deployment based on ceph and opensds will be put into 'ci' directory. Change-Id: I46a32218884c75dda2936337604ff03c554648e4 Signed-off-by: Qiaowei Ren <qiaowei.ren@intel.com>
Diffstat (limited to 'src/ceph/CodingStyle')
-rw-r--r--src/ceph/CodingStyle131
1 files changed, 131 insertions, 0 deletions
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.