From c885dc260bf95fc8a720a03c90e2436a33d82119 Mon Sep 17 00:00:00 2001 From: Daniel Cheng Date: Thu, 13 Nov 2025 09:00:05 -0800 Subject: [PATCH] Update C++ style guide (#949) - Clarify that TODO styles are listed in order of preference - No space between type and `*` or `&` - Minor wording updates for structs and move semantics - Allow naming exceptions for Rust interop --- cppguide.html | 57 +++++++++++++++++++++++++++++---------------------- 1 file changed, 32 insertions(+), 25 deletions(-) diff --git a/cppguide.html b/cppguide.html index 3217b9f..7c6db3c 100644 --- a/cppguide.html +++ b/cppguide.html @@ -754,6 +754,12 @@ using ::absl::container_internal::ImplementationDetail;

  • Single-line nested namespace declarations are preferred in new code, but are not required.

    +
    namespace my_project::my_component {
+
+  ...
+
+}  // namespace my_project::my_component
+
    • @@ -1519,11 +1525,12 @@ defining.

    structs should be used for passive objects that carry data, and may have associated constants. All fields must be public. The -struct must not have invariants that imply relationships between +struct type itself must not have invariants that imply relationships between different fields, since direct user access to those fields may -break those invariants. Constructors, destructors, and helper methods may -be present; however, these methods must not require or enforce any -invariants.

    +break those invariants, but users of a struct may have requirements and +guarantees on particular uses of it. Constructors, destructors, and helper +methods may be present; however, these methods must not require or enforce +any invariants.

    If more functionality or invariants are required, or struct has wide visibility and expected to evolve, then a class is more appropriate. If in doubt, make it a class. @@ -1927,8 +1934,8 @@ instead.

    class MyClass {
  public:
-  void Analyze(const std::string &text);
-  void Analyze(const char *text, size_t textlen);
+  void Analyze(const std::string& text);
+  void Analyze(const char* text, size_t textlen);
 };
    @@ -2021,13 +2028,13 @@ doubt, use overloads.

    C++ allows two different forms of function declarations. In the older form, the return type appears before the function name. For example:

    -
    int foo(int x);
+
    int Foo(int x);
 
    
 
    The newer form uses the auto
   keyword before the function name and a trailing return type after
   the argument list. For example, the declaration above could
   equivalently be written:
    
-
    auto foo(int x) -> int;
+
    auto Foo(int x) -> int;
 
    
 
    The trailing return type is in the function's scope. This doesn't
   make a difference for a simple case like int but it matters
@@ -2046,17 +2053,16 @@ doubt, use overloads.
    
   particularly true when the return type depends on template parameters.
   For example:
    
   
        template <typename T, typename U>
-    auto add(T t, U u) -> decltype(t + u);
+    auto Add(T t, U u) -> decltype(t + u);
   
    
   versus
   
        template <typename T, typename U>
-    decltype(declval<T&>() + declval<U&>()) add(T t, U u);
+    decltype(declval<T&>() + declval<U&>()) Add(T t, U u);
   
    
 
 
    
-
    Trailing return type syntax is relatively new and it has no
-  analogue in C++-like languages such as C and Java, so some readers may
-  find it unfamiliar.
    
+
    Trailing return type syntax has no analogue in C++-like languages
+  such as C and Java, so some readers may find it unfamiliar.
    
 
    Existing codebases have an enormous number of function
   declarations that aren't going to get changed to use the new syntax,
   so the realistic choices are using the old syntax only or using a mixture
@@ -2169,8 +2175,8 @@ all copies, and the object is deleted when the last
   where the resource releases take place.
 
   
  • std::unique_ptr expresses ownership
-  transfer using move semantics, which are
-  relatively new and may confuse some programmers.
    • 
+  transfer using move semantics, which can be complex and
+  may confuse some programmers.
 
   
  • Shared ownership can be a tempting alternative to
   careful ownership design, obfuscating the design of a
@@ -2925,7 +2931,7 @@ be clearly documented as "thread-unsafe".
    
 
 
    Where to put the const
    
 
-
    Some people favor the form int const *foo
+
    Some people favor the form int const* foo
 to const int* foo. They argue that this is
 more readable because it's more consistent: it keeps the
 rule that const always follows the object
@@ -4493,10 +4499,10 @@ class UrlTableTester { ...
 struct UrlTableProperties { ...
 
 // typedefs
-typedef hash_map<UrlTableProperties *, std::string> PropertiesMap;
+typedef hash_map<UrlTableProperties*, std::string> PropertiesMap;
 
 // using aliases
-using PropertiesMap = hash_map<UrlTableProperties *, std::string>;
+using PropertiesMap = hash_map<UrlTableProperties*, std::string>;
 
 // enums
 enum class UrlTableError { ...
@@ -4696,8 +4702,8 @@ than where the original name appears.
    
 
 
    Exceptions to Naming Rules
    
 
-
    If you are naming something that is analogous to an
-existing C or C++ entity then you can follow the existing
+
    If you are naming something that is analogous to an existing C or C++
+entity (or a Rust entity via interop), then you can follow the existing
 naming convention scheme.
    
 
 
    
@@ -5056,9 +5062,10 @@ a short-term solution, or good-enough but not perfect.
    
 
    TODOs should include the string
 TODO in all caps, followed by the bug ID, name, e-mail address, or other identifier
 of the person or issue with the best context
-about the problem referenced by the TODO.
+about the problem referenced by the TODO.
    
+
    Recommended styles are (in order of preference):
    
 
-
    // TODO: bug 12345678 - Remove this after the 2047q4 compatibility window expires.
+
    // TODO: bug 12345678 - Remove this after the 2047q4 compatibility window expires.
 // TODO: example.com/my-design-doc - Manually fix up this code the next time it's touched.
 // TODO(bug 12345678): Update this list after the Foo service is turned down.
 // TODO(John): Use a "\*" here for concatenation operator.
@@ -5979,8 +5986,8 @@ if (x && !y)
 std::vector<std::string> x;
 y = static_cast<char*>(x);
 
-// Spaces between type and pointer are OK, but be consistent.
-std::vector<char *> x;
+// No spaces between type and pointer.
+std::vector<char*> x;
 
    
 
 
    Vertical Whitespace
    
@@ -6048,7 +6055,7 @@ style:
    
   and encouraged, that you use these types when calling
   Windows API functions. Even so, keep as close as you
   can to the underlying C++ types. For example, use
-  const TCHAR * instead of
+  const TCHAR* instead of
   LPCTSTR.
    • 
 
   
  • When compiling with Microsoft Visual C++, set the