parent
85be13d9a3
commit
bab3c36efb
|
@ -37,10 +37,8 @@ Dependencies can be added by using `go mod get`. In order to keep the
|
||||||
|
|
||||||
### Coding Guidelines
|
### Coding Guidelines
|
||||||
|
|
||||||
All Go code should conform to the [Go style guidelines][gostyle]. C++ code
|
All code should comply with the [style guide](g3doc/style.md). Note that code
|
||||||
should conform to the [Google C++ Style Guide][cppstyle] and the guidelines
|
may be automatically formatted per the guidelines when merged.
|
||||||
described for tests. Note that code may be automatically formatted per the
|
|
||||||
guidelines when merged.
|
|
||||||
|
|
||||||
As a secure runtime, we need to maintain the safety of all of code included in
|
As a secure runtime, we need to maintain the safety of all of code included in
|
||||||
gVisor. The following rules help mitigate issues.
|
gVisor. The following rules help mitigate issues.
|
||||||
|
@ -125,9 +123,7 @@ Contributions made by corporations are covered by a different agreement than the
|
||||||
one above, the
|
one above, the
|
||||||
[Software Grant and Corporate Contributor License Agreement][gccla].
|
[Software Grant and Corporate Contributor License Agreement][gccla].
|
||||||
|
|
||||||
[cppstyle]: https://google.github.io/styleguide/cppguide.html
|
|
||||||
[gcla]: https://cla.developers.google.com/about/google-individual
|
[gcla]: https://cla.developers.google.com/about/google-individual
|
||||||
[gccla]: https://cla.developers.google.com/about/google-corporate
|
[gccla]: https://cla.developers.google.com/about/google-corporate
|
||||||
[github]: https://github.com/google/gvisor/compare
|
[github]: https://github.com/google/gvisor/compare
|
||||||
[gvisor-dev-list]: https://groups.google.com/forum/#!forum/gvisor-dev
|
[gvisor-dev-list]: https://groups.google.com/forum/#!forum/gvisor-dev
|
||||||
[gostyle]: https://github.com/golang/go/wiki/CodeReviewComments
|
|
||||||
|
|
|
@ -0,0 +1,88 @@
|
||||||
|
# Provisional style guide
|
||||||
|
|
||||||
|
> These guidelines are new and may change. This note will be removed when
|
||||||
|
> consensus is reached.
|
||||||
|
|
||||||
|
Not all existing code will comply with this style guide, but new code should.
|
||||||
|
Further, it is a goal to eventually update all existing code to be in
|
||||||
|
compliance.
|
||||||
|
|
||||||
|
## All code
|
||||||
|
|
||||||
|
### Early exit
|
||||||
|
|
||||||
|
All code, unless it substantially increases the line count or complexity, should
|
||||||
|
use early exits from loops and functions where possible.
|
||||||
|
|
||||||
|
## Go specific
|
||||||
|
|
||||||
|
All Go code should comply with the [Go Code Review Comments][gostyle] and
|
||||||
|
[Effective Go][effective_go] guides, as well as the additional guidelines
|
||||||
|
described below.
|
||||||
|
|
||||||
|
### Mutexes
|
||||||
|
|
||||||
|
#### Naming
|
||||||
|
|
||||||
|
Mutexes should be named mu or xxxMu. Mutexes as a general rule should not be
|
||||||
|
exported. Instead, export methods which use the mutexes to avoid leaky
|
||||||
|
abstractions.
|
||||||
|
|
||||||
|
#### Location
|
||||||
|
|
||||||
|
Mutexes should be sibling fields to the fields that they protect. Mutexes should
|
||||||
|
not be declared as global variables, instead use a struct (anonymous ok, but
|
||||||
|
naming conventions still apply).
|
||||||
|
|
||||||
|
Mutexes should be ordered before the fields that they protect.
|
||||||
|
|
||||||
|
#### Comments
|
||||||
|
|
||||||
|
Mutexes should have a comment on their declaration explaining any ordering
|
||||||
|
requirements (or pointing to where this information can be found), if
|
||||||
|
applicable. There is no need for a comment explaining which fields are
|
||||||
|
protected.
|
||||||
|
|
||||||
|
Each field or variable protected by a mutex should state as such in a comment on
|
||||||
|
the field or variable declaration.
|
||||||
|
|
||||||
|
### Unused returns
|
||||||
|
|
||||||
|
Unused returns should be explicitly ignored with underscores. If there is a
|
||||||
|
function which is commonly used without using its return(s), a wrapper function
|
||||||
|
should be declared which explicitly ignores the returns. That said, in many
|
||||||
|
cases, it may make sense for the wrapper to check the returns.
|
||||||
|
|
||||||
|
### Formatting verbs
|
||||||
|
|
||||||
|
Built-in types should use their associated verbs (e.g. %d for integral types),
|
||||||
|
but other types should use a %v variant, even if they implement fmt.Stringer.
|
||||||
|
The built-in `error` type should use %w when formatted with `fmt.Errorf`, but
|
||||||
|
only then.
|
||||||
|
|
||||||
|
### Wrapping
|
||||||
|
|
||||||
|
Comments should be wrapped at 80 columns with a 2 space tab size.
|
||||||
|
|
||||||
|
Code does not need to be wrapped, but if wrapping would make it more readable,
|
||||||
|
it should be wrapped with each subcomponent of the thing being wrapped on its
|
||||||
|
own line. For example, if a struct is split between lines, each field should be
|
||||||
|
on its own line.
|
||||||
|
|
||||||
|
#### Example
|
||||||
|
|
||||||
|
```go
|
||||||
|
_ = exec.Cmd{
|
||||||
|
Path: "/foo/bar",
|
||||||
|
Args: []string{"-baz"},
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
## C++ specific
|
||||||
|
|
||||||
|
C++ code should conform to the [Google C++ Style Guide][cppstyle] and the
|
||||||
|
guidelines described for tests.
|
||||||
|
|
||||||
|
[cppstyle]: https://google.github.io/styleguide/cppguide.html
|
||||||
|
[gostyle]: https://github.com/golang/go/wiki/CodeReviewComments
|
||||||
|
[effective_go]: https://golang.org/doc/effective_go.html
|
Loading…
Reference in New Issue