From: Sage Weil <sage@redhat.com>
Date: Wed, 23 May 2018 02:40:11 +0000 (-0500)
Subject: CodingStyle: a few updates
X-Git-Tag: v14.0.0~16^2~2
X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=69a1715a74cc8dd418798f573e52535469262922;p=ceph.git

CodingStyle: a few updates

The C++ style was originally adopted in 2011.  Most of the guidelines
have been followed but some have not.  Drop the ones we haven't been
following.

Signed-off-by: Sage Weil <sage@redhat.com>
---

diff --git a/CodingStyle b/CodingStyle
index d3d21e1d553f..7c9035e65e03 100644
--- a/CodingStyle
+++ b/CodingStyle
@@ -28,12 +28,12 @@ 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 {
+        struct my_type_t {
           int a, b;
-          my_type_d() : a(0), b(0) {}
+          my_type_t() : a(0), b(0) {}
         };
 
     - for full-blown classes, CamelCaps, private: section, accessors,
@@ -42,7 +42,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:
@@ -88,16 +88,18 @@ 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