From 7da45d65be36d36b880cc55c5036e96c24b53f00 Mon Sep 17 00:00:00 2001 From: Qiaowei Ren Date: Thu, 1 Mar 2018 14:38:11 +0800 Subject: remove ceph code This patch removes initial ceph code, due to license issue. Change-Id: I092d44f601cdf34aed92300fe13214925563081c Signed-off-by: Qiaowei Ren --- src/ceph/CodingStyle | 131 --------------------------------------------------- 1 file changed, 131 deletions(-) delete mode 100644 src/ceph/CodingStyle (limited to 'src/ceph/CodingStyle') diff --git a/src/ceph/CodingStyle b/src/ceph/CodingStyle deleted file mode 100644 index 870c0ce..0000000 --- a/src/ceph/CodingStyle +++ /dev/null @@ -1,131 +0,0 @@ -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. -- cgit 1.2.3-korg