The Fuchsia project follows the public Google C++ style guide, with a few exceptions.
Using 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.
The Google C++ style guide requires referencing a bug number in TODO comments. On Fuchsia this is done in the format: TODO(fxbug.dev/12345)
.
Please do not add -Wall
or -Wextra
.
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.
source_set("my_sources") { ... cflags = [ # We don't want any write-only params/vars in our code. # TODO(fxbug.dev/56202): delete the below when these warnings are # enabled globally. "-Wunused-but-set-parameter", "-Wunused-but-set-variable", ] }
Fuchsia uses 100 columns instead of 80.
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.
// Don't do this. while (!done) doSomethingWithAReallyLongLine( wrapped_arg); // Correct. while (!done) { doSomethingWithAReallyLongLine( wrapped_arg); }
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):
// Don't do this: if (x == kFoo) return new Foo(); // Correct. if (x == kFoo) return new Foo;
internal
(when required to hide implementation details of templated code)internal
fuchsia
(except in code generated by the FIDL compiler)media
) are best avoided.Rationale: Tip of the Week #130: Namespace Naming
If the header being included is a system, global, or library header (see Naming C/C++ objects 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:
#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:
#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>
).