# google.github.io - Google C++ Style Guide (Highlights) ![rw-book-cover|256](https://rdl.ink/render/https%3A%2F%2Fgoogle.github.io%2Fstyleguide%2Fcppguide.html) ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/56173261) **Source**:: #from/readwise #from/reader **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[google.github.io]] **Full Title**:: Google C++ Style Guide **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [google.github.io](https://google.github.io/styleguide/cppguide.html) **Host**:: [[google.github.io]] **Highlighted**:: [[2025-11-11]] **Created**:: [[2025-11-15]] ## Highlights - Currently, code should target C++20, i.e., should not use C++23 features. ([View Highlight](https://read.readwise.io/read/01k9r2ayye7kvrvy6ha79pmjv5)) ^956310231 - All header files should have `#define` guards to prevent multiple inclusion. The format of the symbol name should be `*<PROJECT>*_*<PATH>*_*<FILE>*_H_`. ([View Highlight](https://read.readwise.io/read/01k9r2c51vapjnywch9pc16v19)) ^956310288 - `foo.cc` should include `bar.h` if it uses a symbol from it even if `foo.h` includes `bar.h`. ([View Highlight](https://read.readwise.io/read/01k9r2dwdzv425qbyqcf44ywtk)) ^956310443 - Avoid using forward declarations where possible. Instead, [include the headers you need](https://google.github.io/styleguide/cppguide.html/#Include_What_You_Use). ([View Highlight](https://read.readwise.io/read/01k9r2e71p7kmtz10y0krar3kp)) ^956310464 - Try to avoid forward declarations of entities defined in another project. ([View Highlight](https://read.readwise.io/read/01k9r2gj5rrn99nmq7regdqnq7)) ^956310796 - Even if a definition must be in the header, this is not a sufficient reason to put it within the public part. Instead, the definition can be in an internal part of the header, such as the [private](https://google.github.io/styleguide/cppguide.html/#Access_Control) section of a class, within a namespace that includes the word `internal`, or below a comment like `// Implementation details only below here`. ([View Highlight](https://read.readwise.io/read/01k9r2j7stzqakws5bwcd5vtq6)) ^956311027 - Include headers in the following order: Related header, C system headers, C++ standard library headers, other libraries' headers, your project's headers. ([View Highlight](https://read.readwise.io/read/01k9r2kdetjrj7ajbvz4rzqzsw)) ^956311193 - When definitions in a `.cc` file do not need to be referenced outside that file, give them internal linkage by placing them in an unnamed namespace or declaring them `static`. Do not use either of these constructs in `.h` files. ([View Highlight](https://read.readwise.io/read/01k9r2tjhgf21chrcs4crbv0bd)) ^956312098 - Use trailing return types only where using the ordinary syntax (leading return types) is impractical or much less readable. ([View Highlight](https://read.readwise.io/read/01k9r34qrm75cpf52vm5sj9yx0)) ^956313409 - We do not use C++ exceptions. ([View Highlight](https://read.readwise.io/read/01k9r3n8qhcpjxf2bgh5dsvnv3)) ^956314174 - Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. ([View Highlight](https://read.readwise.io/read/01k9r3r460qm03adw3zjk6mphj)) ^956314266 - Use C++-style casts like `static_cast<float>(double_value)`, or brace initialization for conversion of arithmetic types like `int64_t y = int64_t{1} << 42`. Do not use cast formats like `(int)x` unless the cast is to `void`. You may use cast formats like `T(x)` only when `T` is a class type. ([View Highlight](https://read.readwise.io/read/01k9r4vj28xbbdsx7kg42tezn3)) ^956329231 - `constexpr` definitions enable a more robust specification of the constant parts of an interface. Use `constexpr` to specify true constants and the functions that support their definitions. `consteval` may be used for code that must not be invoked at runtime. Avoid complexifying function definitions to enable their use with `constexpr`. Do not use `constexpr` or `consteval` to force inlining. ([View Highlight](https://read.readwise.io/read/01k9r4y4wwpw6b59jywak6rahe)) ^956329707 - The best advice we can provide: try to use iterators and containers rather than pointers and sizes, try not to mix signedness, and try to avoid unsigned types (except for representing bitfields or modular arithmetic). Do not use an unsigned type merely to assert that a variable is non-negative. ([View Highlight](https://read.readwise.io/read/01k9r50mqwr30gg4034jz2ytr2)) ^956329820 - Avoid defining macros, especially in headers; prefer inline functions, enums, and `const` variables. Name macros with a project-specific prefix. Do not use macros to define pieces of a C++ API. ([View Highlight](https://read.readwise.io/read/01k9r51ftwc9n23tbjv9682y6k)) ^956329845 - Prefer `sizeof(varname)` to `sizeof(type)`. ([View Highlight](https://read.readwise.io/read/01k9r5293m7bstkjf8y23v6x38)) ^956329881 - Use designated initializers only in their C++20-compliant form. ([View Highlight](https://read.readwise.io/read/01k9r53qmx5rq0dqdy2r6b6p9f)) ^956329980 - The `<filesystem>` header, which does not have sufficient support for testing, and suffers from inherent security vulnerabilities. ([View Highlight](https://read.readwise.io/read/01k9r5818frcqxvwhanprx6bb1)) ^956330246 - Fall-through from one case label to another must be annotated using the `[[fallthrough]];` attribute. `[[fallthrough]];` should be placed at a point of execution where a fall-through to the next case label occurs. A common exception is consecutive case labels without intervening code, in which case no annotation is needed. ([View Highlight](https://read.readwise.io/read/01k9r59xh74byqwt8wkzqj8q8w)) ^956330433 - Filenames should be all lowercase and can include underscores (`_`) or dashes (`-`). Follow the convention that your project uses. If there is no consistent local pattern to follow, prefer "`_`". ([View Highlight](https://read.readwise.io/read/01k9r5bemz4x4nqb55338er53k)) ^956330476 - Type names start with a capital letter and have a capital letter for each new word, with no underscores: `MyExcitingClass`, `MyExcitingEnum`. ([View Highlight](https://read.readwise.io/read/01k9r5br1ygtbsatj1nmdpnmvr)) ^956330490 - The names of variables (including function parameters) and data members are `snake_case` (all lowercase, with underscores between words). Data members of classes (but not structs) additionally have trailing underscores. For instance: `a_local_variable`, `a_struct_data_member`, `a_class_data_member_`. ([View Highlight](https://read.readwise.io/read/01k9r5cgcddjm9jr6jwegd2r08)) ^956330520 - Variables declared `constexpr` or `const`, and whose value is fixed for the duration of the program, are named with a leading "k" followed by mixed case. Underscores can be used as separators in the rare cases where capitalization cannot be used for separation. ([View Highlight](https://read.readwise.io/read/01k9r5dtrb86z8byfvz0xww063)) ^956330594 - Ordinarily, functions follow [PascalCase](https://en.wiktionary.org/wiki/Pascal_case): start with a capital letter and have a capital letter for each new word. ([View Highlight](https://read.readwise.io/read/01k9r5e3ryxqt343wejhq5kkta)) ^956330601 - Namespace names are `snake_case` (all lowercase, with underscores between words). ([View Highlight](https://read.readwise.io/read/01k9r5e98e3xb4978dx4r4ys7p)) ^956330604 - Enumerators (for both scoped and unscoped enums) should be named like [constants](https://google.github.io/styleguide/cppguide.html/#Constant_Names), not like [macros](https://google.github.io/styleguide/cppguide.html/#Macro_Names). ([View Highlight](https://read.readwise.io/read/01k9r5ej5z794mzcgpb7rgqjtp)) ^956330613 - Use only spaces, and indent 2 spaces at a time. ([View Highlight](https://read.readwise.io/read/01k9r5gxh190mwenmrc6fzbg2z)) ^956330704