The Fuchsia project follows the publicGoogle C++ style guide, with afew exceptions.

Usingclang-format is a good practice as it ensures your code is incompliance with the style guide. Tricium checks in Gerrit also use clang-format as anon-gating linter. However, you may still manually format code as long as it complieswith 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.

source_set("my_sources") {  ...  cflags = [    # Don't do this!    "-Wall",  ]}

This flag is already added in a centralized place in the build, followed byadditional flags that suppress certain warnings globally.

Occasionally new compiler warnings are added upstream. In order to roll thelatest compiler, global maintainers may opt to temporarily suppress anewly-introduced warning in a centralized place while we work through a backlogof fixing instances of this warning throughout the codebase. If your projectuses-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 yourown 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(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 addthese.

// 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 butpermits this).

Do not use the single-line form for short conditionals and loops (the Googlestyle guide permits both forms):

// Don't do this:if(x==kFoo)returnnewFoo();// Correct.if(x==kFoo){returnnewFoo;}

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 themeantime, new namespaces should be introduced thoughtfully.
• Namespaces in non-IDK libraries should also be chosen so as to reduce the riskof clashes. Very generic nouns (eg.media) are best avoided.

Rationale:Tip of the Week #130: Namespace Naming

Includes

• If the header being included is a system, global, or library header (seeNaming C/C++ objects for precise definitions), use<angle brackets> and the complete name of the header. These headers areconsidered "C library headers" for the purposes of the Google C++ StyleGuide:

  #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" anduse the full path to the header from the root of the source tree. Theseheaders are considered "your project's headers" for the purposes of theGoogle 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 headernames (e.g.#include <gtest/gtest.h>).