| # C++ style guide | |
| The Fuchsia project follows the public [Google C++ style guide][google-guide], with a | |
| few exceptions. | |
| Using [clang-format][clang-format] is a good practice as it ensures your code is in | |
| compliance with the style guide. Tricium checks in Gerrit also use clang-format as a | |
| non-gating linter. However, you may still manually format code as long as it complies | |
| with these guidelines. | |
| ## Fuchsia-specific style | |
| ### TODO comments | |
| The Google C++ style guide requires referencing a bug number in TODO comments. | |
| On Fuchsia this is done in the format: `TODO(https://fxbug.dev/42074368)`. | |
| ### Compilation flags | |
| Please do not add `-Wall` or `-Wextra`. | |
| ```gn | |
| source_set("my_sources") { | |
| ... | |
| cflags = [ | |
| # Don't do this! | |
| "-Wall", | |
| ] | |
| } | |
| ``` | |
| This flag is already added in a centralized place in the build, followed by | |
| additional flags that suppress certain warnings globally. | |
| Occasionally new compiler warnings are added upstream. In order to roll the | |
| latest compiler, global maintainers may opt to temporarily suppress a | |
| newly-introduced warning in a centralized place while we work through a backlog | |
| of fixing instances of this warning throughout the codebase. If your project | |
| uses `-Wall` then it may break with a Clang roll. | |
| Do feel free to enable/disable specific warnings that are not set globally. | |
| If these warnings are set globally later in a manner that's congruent with your | |
| own preferences then it's a good idea to remove any local overrides. | |
| ```gn | |
| source_set("my_sources") { | |
| ... | |
| cflags = [ | |
| # We don't want any write-only params/vars in our code. | |
| # TODO(https://fxbug.dev/42133916): delete the below when these warnings are | |
| # enabled globally. | |
| "-Wunused-but-set-parameter", | |
| "-Wunused-but-set-variable", | |
| ] | |
| } | |
| ``` | |
| ## Exceptions | |
| ### Line length | |
| Fuchsia uses 100 columns instead of 80. | |
| ### Braces | |
| Always use braces `{ }` when the contents of a block are more than one line. | |
| This is something you need to watch since Clang-format doesn't know to add | |
| these. | |
| ```cpp | |
| // Don't do this. | |
| while (!done) | |
| doSomethingWithAReallyLongLine( | |
| wrapped_arg); | |
| // Correct. | |
| while (!done) { | |
| doSomethingWithAReallyLongLine( | |
| wrapped_arg); | |
| } | |
| ``` | |
| ### Conditionals and loops | |
| Do not use spaces inside parentheses (the Google style guide discourages but | |
| permits this). | |
| Do not use the single-line form for short conditionals and loops (the Google | |
| style guide permits both forms): | |
| ```cpp | |
| // Don't do this: | |
| if (x == kFoo) return new Foo(); | |
| // Correct. | |
| if (x == kFoo) { | |
| return new Foo; | |
| } | |
| ``` | |
| ### Namespace names | |
| * Nested namespaces are forbidden, with the following exceptions: | |
| - `internal` (when required to hide implementation details of templated code) | |
| - code generated by the FIDL compiler | |
| * The following top-level namespaces are forbidden: | |
| - `internal` | |
| - `fuchsia` (except in code generated by the FIDL compiler) | |
| * Namespaces in IDK libraries must be kept to as short a list as possible. | |
| A later document will provide an explicit list of allowed namespaces; in the | |
| meantime, new namespaces should be introduced thoughtfully. | |
| * Namespaces in non-IDK libraries should also be chosen so as to reduce the risk | |
| of clashes. Very generic nouns (eg. `media`) are best avoided. | |
| Rationale: [Tip of the Week #130: Namespace Naming][totw-130] | |
| [clang-format]: https://clang.llvm.org/docs/ClangFormat.html | |
| [google-guide]: https://google.github.io/styleguide/cppguide.html | |
| [totw-130]: https://abseil.io/tips/130 | |
| ### Includes | |
| * If the header being included is a system, global, or library header (see | |
| [Naming C/C++ objects](naming.md) for precise definitions), use | |
| `<angle brackets>` and the complete name of the header. These headers are | |
| considered "C library headers" for the purposes of the Google C++ Style | |
| Guide: | |
| ```cpp | |
| #include <zircon/syscalls.h> // System header | |
| #include <fuchsia/io/cpp/fidl.h> // Global header | |
| #include <lib/fdio/fd.h> // Library header | |
| ``` | |
| * If the header being included is a implementation header, use `"quotes"` and | |
| use the full path to the header from the root of the source tree. These | |
| headers are considered "your project's headers" for the purposes of the | |
| Google C++ Style Guide: | |
| ```cpp | |
| #include "src/ui/scenic/bin/app.h" // Implementation header | |
| ``` | |
| * Third-party headers can be included using the root-relative path (e.g. | |
| `#include "third_party/skia/include/core/SkPaint.h"`) or using their canonical header | |
| names (e.g. `#include <gtest/gtest.h>`). |