From ed3dd33df34a145cc56bcf0f3e99b91e7a5a5f86 Mon Sep 17 00:00:00 2001 From: Daniel Cheng Date: Tue, 10 Nov 2020 22:26:05 -0800 Subject: [PATCH] Update Google C++ styleguide - Guidance for return values (prefer return by value, return by reference, then return by pointer in that order) - Mandate curly braces around the body of a control statement, providing one exception for historical reasons (`if` with no `else`, and `if` + body fits completely in a single line or the `if` fits in one line and the body fits in another separate line). --- cppguide.html | 140 ++++++++++++++++++++++++-------------------------- 1 file changed, 66 insertions(+), 74 deletions(-) diff --git a/cppguide.html b/cppguide.html index 6c52c11..b90d898 100644 --- a/cppguide.html +++ b/cppguide.html @@ -1693,8 +1693,8 @@ earlier.

protected:, then private:. Omit sections that would be empty.

-

Within each section, generally prefer grouping similar -kinds of declarations together, and generally prefer the +

Within each section, prefer grouping similar +kinds of declarations together, and prefer the following order: types (including typedef, using, and nested structs and classes), constants, factory functions, constructors and assignment @@ -1719,6 +1719,9 @@ a return value and sometimes via output parameters (or in/out parameters).

improve readability, and often provide the same or better performance.

+

Prefer to return by value or, failing that, return by reference. +Avoid returning a pointer unless it can be null.

+

Parameters are either inputs to the function, outputs from the function, or both. Input parameters should usually be values or const references, while non-optional output and @@ -2077,9 +2080,7 @@ do use shared ownership, prefer to use is a tool that reads a source file and identifies many style errors. It is not perfect, and has both false positives and false negatives, but it is still a valuable -tool. False positives can be ignored by putting // -NOLINT at the end of the line or -// NOLINTNEXTLINE in the previous line.

+tool.

@@ -4044,7 +4045,7 @@ and avoid terms that other programmers might find disrespectful or offensive (such as "master" and "slave", "blacklist" and "whitelist", or "redline"), even if the terms also have an ostensibly neutral meaning. Similarly, use gender-neutral language unless you're referring -to a specific person (and using their preferred pronouns). For example, +to a specific person (and using their pronouns). For example, use "they"/"them"/"their" for people of unspecified gender (even when singular), and "it"/"its" for software, computers, and other @@ -4621,7 +4622,7 @@ obvious. For example:

are, what they are used for, and (if unclear) why it needs to be global. For example:

-
// The total number of tests cases that we run through in this regression test.
+
// The total number of test cases that we run through in this regression test.
 const int kNumTestCases = 6;
 

 
@@ -5178,92 +5179,83 @@ MyType m = {  // Here, you could also break before {.
 
 
Conditionals

 
-
Each of if, else, and else if
-  belong on separate lines. There should be a space between
-  the if and the open parenthesis, and between the close
-  parenthesis and the curly brace (if any), but no space between the
-  parentheses and the condition.

+
In an if statement, including its optional else if
+and else clauses, put one space between the if and the
+opening parenthesis, and between the closing parenthesis and the curly brace (if
+any), but no spaces between the parentheses and the condition or initializer. If
+the optional initializer is present, put a space or newline after the semicolon,
+but not before.

 
-
if (condition) {  // no spaces inside parentheses
-  ...  // 2 space indent.
-} else if (...) {  // The else goes on the same line as the closing brace.
-  ...
+
if(condition) {              // Bad - space missing after IF
+if ( condition ) {           // Bad - space between the parentheses and the condition
+if (condition){              // Bad - space missing before {
+if(condition){               // Doubly bad
+
+if (int a = f();a == 10) {   // Bad - space missing after the semicolon
+

+
+
Use curly braces for the controlled statements following
+if, else if and else. Break the line
+immediately after the opening brace, and immediately before the closing brace. A
+subsequent else, if any, appears on the same line as the preceding
+closing brace, separated by a space.

+
+
if (condition) {                   // no spaces inside parentheses, space before brace
+  DoOneThing();                    // two space indent
+  DoAnotherThing();
+} else if (int a = f(); a != 3) {  // closing brace on new line, else on same line
+  DoAThirdThing(a);
 } else {
-  ...
+  DoNothing();
 }
 

 
-
if(condition) {   // Bad - space missing after IF.
-if ( condition ) { // Bad - space between the parentheses and the condition
-if (condition){   // Bad - space missing before {.
-if(condition){    // Doubly bad.
-

-
-
if (condition) {  // Good - proper space after IF and before {.
-

-
-
Short conditional statements may be written on one
-line if this enhances readability. You may use this only
-when the line is brief and the statement does not use the
-else clause.

+
For historical reasons, we allow one exception to the above rules: if an
+if statement has no else or else if
+clauses, then the curly braces for the controlled statement or the line breaks
+inside the curly braces may be omitted if as a result the entire if
+statement appears on either a single line (in which case there is a space
+between the closing parenthesis and the controlled statement) or on two lines
+(in which case there is a line break after the closing parenthesis and there are
+no braces). For example, the following forms are allowed under this
+exception.

 
 
if (x == kFoo) return new Foo();
-if (x == kBar) return new Bar();
+
+if (x == kBar)
+  return new Bar(arg1, arg2, arg3);
+
+if (x == kQuz) { return new Quz(1, 2, 3); }
 

 
-
This is not allowed when the if statement has an
-else:

+
Use this style only when the statement is brief, and consider that
+conditional statements with complex conditions or controlled statements may be
+more readable with curly braces. Some
+projects
+require curly braces always.

 
-
// Not allowed - IF statement on one line when there is an ELSE clause
+
Finally, these are not permitted:

+
+
// Bad - IF statement with ELSE is missing braces
 if (x) DoThis();
 else DoThat();
-

 
-
In general, curly braces are not required for
-single-line statements, but they are allowed if you like
-them; conditional or loop statements with complex
-conditions or statements may be more readable with curly
-braces. Some
-projects require that an
-if must always have an accompanying
-brace.

-
-
if (condition)
-  DoSomething();  // 2 space indent.
-
-if (condition) {
-  DoSomething();  // 2 space indent.
-}
-

-
-
However, if one part of an
-if-else or an
-if-else if-else statement uses curly
-braces, the other part(s) must, too:

-
-
// Not allowed - curly on IF but not ELSE
-if (condition) {
-  foo;
-} else
-  bar;
-
-// Not allowed - curly on ELSE but not IF
+// Bad - IF statement with ELSE does not have braces everywhere
 if (condition)
   foo;
 else {
   bar;
 }
-

 
-
// Curly braces around IF, ELSE IF, and ELSE required because
-// one of the clauses used braces.
-if (condition) {
-  foo;
-} else if (other_condition) {
-  frob;
-} else {
-  bar;
-}
+// Bad - IF statement is too long to omit braces
+if (condition)
+  // Comment
+  DoSomething();
+
+// Bad - IF statement is too long to omit braces
+if (condition1 &&
+    condition2)
+  DoSomething();
 

 
 
Loops and Switch Statements