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 d3d21e1d553f14456b9abb939ab1d552ab0a419c..7c9035e65e03bd58e11181de619a9d0c3ee1ac58 100644 (file)
--- 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