BUILD style guide
BUILD files, we take the same approach as in Go: We let the machine take care
of most formatting issues.
Buildifier is a tool that parses and
emits the source code in a standard style. Every
BUILD file is therefore
formatted in the same automated way, which makes formatting a non-issue during
code reviews. It also makes it easier for tools to understand, edit, and
BUILD file formatting must match the output of
# Test code implmenting the Foo controller. package(default_visibility = ["//visibility:public"]) py_test( name = "foo_test", srcs = glob(["*.py"]), data = [ "//data/production/foo:startfoo", "//foo", "//third_party/java/jdk:jdk-k8", ], flaky = True, deps = [ ":check_bar_lib", ":foo_data_check", ":pick_foo_port", "//pyglib", "//testing/pybase", ], )
We recommend to use the following order (every element is optional):
Package description (a comment)
Calls to rules and macros
Buildifier makes a distinction between a standalone comment and a comment attached to an element. If a comment is not attached to a specific element, use an empty line after it. The distinction is important when doing automated changes (e.g. to decide if we keep or remove a comment when we delete a rule).
# Standalone comment (e.g. to make a section in a file) # Comment for the cc_library below cc_library(name = "cc")
References to targets in the current package
Files should be referred to by their paths relative to the package directory
(without ever using up-references, such as
..). Generated files should be
prefixed with “
:” to indicate that they are not sources. Source files
should not be prefixed with
:. Rules should be prefixed with
x.cc is a source file:
cc_library( name = "lib", srcs = ["x.cc"], hdrs = [":gen_header"], ) genrule( name = "gen_header", srcs = , outs = ["x.h"], cmd = "echo 'int x();' > $@", )
Target names should be descriptive. If a target contains one source file,
the target should generally have a name derived from that source (e.g., a
chat.cc could be named “
chat”, or a
DirectMessage.java could be named “
The eponymous target for a package (the target with the same name as the containing directory) should provide the functionality described by the directory name. If there is no such target, do not create an eponymous target.
Prefer using the short name when referring to an eponymous target (
//x:x). If you are in the same package, prefer the local
:x instead of
Avoid using “reserved” target names which have special meaning. This includes
__pkg__”, and “
__subpackages__”, these names have special
semantics and can cause confusion and unexpected behaviors when they are used.
In the absence of a prevailing team convention these are some non-binding recommendations that are broadly used at Google:
- In general, use “snake_case”
- For a java_library with one src this would mean using a name that is not the same as the filename without the extension
- For Java *_binary and *_test rules use “Upper CamelCase”. This allows for the target name to match one of the srcs. For java_test, this makes it possible for the test_class attribute to be inferred from the name of the target.
- If there are multiple variants of a particular target then add a suffix to disambiguate (i.e. :foo_dev, :foo_prod or :bar_x86, :bar_x64)
- _test targets should be suffixed with “_test”, “_unittest”, “Test”, or “Tests”
- Avoid meaningless suffixes like “_lib” or “_library” (unless necessary to avoid conflicts between a _library target and its corresponding _binary)
- For proto related targets:
- proto_library targets should have names ending in “_proto”
- Languages specific *_proto_library rules should match the underlying
proto but replace “_proto” with a language specific suffix such as:
- cc_proto_library: “_cc_proto”
- java_proto_library: “_java_proto”
- java_lite_proto_library: “_java_proto_lite”
Visibility should be scoped as tightly as possible, while still allowing access
by tests and reverse dependencies. Use
Avoid setting package
//visibility:public should be individually set only for targets in the
project’s public API. These could be libraries that are designed to be depended
on by external projects or binaries that could be used by an external project’s
Dependencies should be restricted to direct dependencies (dependencies needed by the sources listed in the rule). Do not list transitive dependencies.
Package-local dependencies should be listed first and referred to in a way compatible with the References to targets in the current package section above (not by their absolute package name).
Prefer to list dependencies directly, as a single list. Putting the “common” dependencies of several targets into a variable reduces maintainability, makes it impossible for tools to change the dependencies of a target and can lead to unused dependencies.
Indicate “no targets” with
. Do not use a glob that matches nothing: it
is more error-prone and less obvious than an empty list.
Do not use recursive globs to match source files (for example,
Recursive globs make BUILD files difficult to reason about because they skip subdirectories containing BUILD files.
Recursive globs are generally less efficient than having a BUILD file per directory with a dependency graph defined between them as this enables better remote caching and parallelism.
We recommend authoring a BUILD file per directory and defining a dependency graph between them instead.
Non-recursive globs are generally acceptable.
Use uppercase and underscores to declare constants (e.g.
GLOBAL_CONSTANT), use lowercase and underscores to declare variables (e.g.
Labels should never be split, even if they are longer than 79 characters. Labels should be string literals whenever possible. Rationale: It makes find and replace easy. It also improves readability.
The value of the name attribute should be a literal constant string (except in macros). Rationale: External tools use the name attribute to refer a rule. They need to find rules without having to interpret code.
When setting boolean-type attributes, use boolean values, not integer values. For legacy reasons, rules will still convert integers to booleans as needed, but this is discouraged. Rationale:
flaky = 1could be misread as saying “deflake this target by rerunning it once”.
flaky = Trueunambiguously says “this test is flaky”.
Differences with Python style guide
Although compatibility with Python style guide is a goal, there are a few differences:
No strict line length limit. Long comments and long strings are often split to 79 columns, but it is not required. It should not be enforced in code reviews or presubmit scripts. Rationale: Labels can be long and exceed this limit. It is common for
BUILDfiles to be generated or edited by tools, which does not go well with a line length limit.
Implicit string concatenation is not supported. Use the
BUILDfiles contain many string lists. It is easy to forget a comma, which leads to a complete different result. This has created many bugs in the past. See also this discussion.
Use spaces around the
=sign for keywords arguments in rules. Rationale: Named arguments are much more frequent than in Python and are always on a separate line. Spaces improve readability. This convention has been around for a long time, and we don’t think it is worth modifying all existing
By default, use double quotation marks for strings. Rationale: This is not specified in the Python style guide, but it recommends consistency. So we decided to use only double-quoted strings. Many languages use double-quotes for string literals.
Use a single blank line between two top-level definitions. Rationale: The structure of a
BUILDfile is not like a typical Python file. It has only top-level statements. Using a single-blank line makes