bump version to 18.2.4-pve3

[ceph.git] / ceph / CodingStyle

diff --git a/ceph/CodingStyle b/ceph/CodingStyle
index 870c0ce5d39dfb2295d34a607d7b155c5a094e3c..659298f0e5ae497d4a0480ae409015d6b7299e37 100644 (file)
--- a/ceph/CodingStyle
+++ b/ceph/CodingStyle
@@ -9,7 +9,7 @@ C code
 
 For C code, we conform by the Linux kernel coding standards:
 
-    https://www.kernel.org/doc/Documentation/CodingStyle
+    https://www.kernel.org/doc/Documentation/process/coding-style.rst
 
 
 C++ code
@@ -28,12 +28,13 @@ by section.
 
     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.
+    - for naked structs (simple data containers), lower case with _t.
+      Yes, _t also means typedef.  It's perhaps not ideal.
 
-        struct my_type_d {
-          int a, b;
-          my_type_d() : a(0), b(0) {}
+        struct my_type_t {
+          int a = 0, b = 0;
+         void encode(...) ...
+         ...
         };
 
     - for full-blown classes, CamelCaps, private: section, accessors,
@@ -42,7 +43,7 @@ by section.
 * Naming > Variable Names:
 
    Google uses _ suffix for class members.  That's ugly.  We'll use
-   a m_ prefix, like so:
+   a m_ prefix, like so, or none at all.
 
         class Foo {
         public:
@@ -52,7 +53,7 @@ by section.
          private:
           int m_foo;
        };
-   
+
 * Naming > Constant Names:
 
    Google uses kSomeThing for constants.  We prefer SOME_THING.
@@ -70,7 +71,7 @@ by section.
 * 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.
+   (LGPL2.1 or LGPL3.0) 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
@@ -78,7 +79,7 @@ by section.
   header is:
 
 // -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*-
-// vim: ts=8 sw=2 smarttab
+// vim: ts=8 sw=2 smarttab ft=cpp
 
 * Formatting > Conditionals:
 
@@ -88,18 +89,24 @@ by section.
 
         if ( foo ) { // no
 
-   - Always use newline following if:
-
-        if (foo)
-          bar;         // okay, but discouraged...
+   - Always use newline following if, and use braces:
 
         if (foo) {
-          bar;         // this is better!
+          bar;         // like this, even for a one-liner
         }
 
-        if (foo) bar;  // no, usually harder to parse visually
+       if (foo)
+         bar;         // no, usually harder to parse visually
+
+        if (foo) bar;  // no
+
+       if (foo) { bar; }  // definitely no
 
+* Header Files -> The `#define` Guard:
 
+  `#pragma once` is allowed for simplicity at the expense of
+   portability since `#pragma once` is widely supported and is known
+   to work on GCC and Clang.
 
 
 The following guidelines have not been followed in the legacy code,
@@ -129,3 +136,29 @@ type conversions.
 * Other C++ Features > Avoid Default Arguments:
 
     They obscure the interface.
+
+
+Python code
+-----------
+
+For new python code, PEP-8 should be observed:
+
+    https://www.python.org/dev/peps/pep-0008/
+
+Existing code can be refactored to adhere to PEP-8, and cleanups are welcome.
+
+
+JavaScript / TypeScript
+-----------------------
+
+For Angular code, we follow the official Angular style guide:
+
+    https://angular.io/guide/styleguide
+
+To check whether your code is conformant with the style guide, we use a
+combination of ESLint, Codelyzer and Prettier:
+
+    https://eslint.org/
+    http://codelyzer.com/
+    https://prettier.io/
+