Add a style guide
Change-Id: I13bf82440cdf5c9268e8cc0d35a1119ebf9a9ed0 Reviewed-on: https://dawn-review.googlesource.com/c/tint/+/42200 Kokoro: Kokoro <noreply+kokoro@google.com> Reviewed-by: Ben Clayton <bclayton@google.com> Commit-Queue: David Neto <dneto@google.com>
This commit is contained in:
parent
80767413b8
commit
fae0aa6e72
|
@ -20,10 +20,7 @@ again.
|
||||||
All submissions, including submissions by project members, require review. We
|
All submissions, including submissions by project members, require review. We
|
||||||
use [Dawn's Gerrit](https://dawn-review.googlesource.com/) for this purpose.
|
use [Dawn's Gerrit](https://dawn-review.googlesource.com/) for this purpose.
|
||||||
|
|
||||||
Tint generally follows the Google C++ style guide. There is a clang-format file
|
Submissions should follow the [Tint style guide](docs/style_guide.md).
|
||||||
provided and a `tools/format` script which will run the formatter. There is also
|
|
||||||
a `tools/lint` script to run a linter. Overall try to use the same style and
|
|
||||||
convention as code around your change.
|
|
||||||
|
|
||||||
## Community Guidelines
|
## Community Guidelines
|
||||||
|
|
||||||
|
|
|
@ -0,0 +1,50 @@
|
||||||
|
# Tint style guide
|
||||||
|
|
||||||
|
* Generally, follow the [Chromium style guide for C++](https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++.md)
|
||||||
|
which itself is built on the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html).
|
||||||
|
|
||||||
|
* Overall try to use the same style and convention as code around your change.
|
||||||
|
|
||||||
|
* Code must be formatted. Use `clang-format` with the provided [.clang-format](../.clang-format)
|
||||||
|
file. The `tools/format` script runs the formatter.
|
||||||
|
|
||||||
|
* Code should not have linting errors.
|
||||||
|
The `tools/lint` script runs the linter. So does `git cl upload`.
|
||||||
|
|
||||||
|
* Do not use C++ exceptions
|
||||||
|
|
||||||
|
* Do not use C++ RTTI.
|
||||||
|
Instead, use `tint::Castable::As<T>()` from
|
||||||
|
[src/castable.h](../src/castable.h)
|
||||||
|
|
||||||
|
* Generally, avoid `assert`. Instead, issue a [diagnostic](../src/diagnostic.h)
|
||||||
|
and fail gracefully, possibly by returning an error sentinel value.
|
||||||
|
Code that should not be reachable should call `TINT_UNREACHABLE` macro
|
||||||
|
and other internal error conditions should call the `TINT_ICE` macro.
|
||||||
|
See [src/debug.h](../src/debug.h)
|
||||||
|
|
||||||
|
* Use `type` as part of a name only when the name refers to a type
|
||||||
|
in WGSL or another shader language processed by Tint. If the concept you are
|
||||||
|
trying to name is about distinguishing between alternatives, use `kind` instead.
|
||||||
|
|
||||||
|
## Compiler support
|
||||||
|
|
||||||
|
Tint requires C++14.
|
||||||
|
|
||||||
|
Tint uses the Chromium build system and will stay synchronized with that system.
|
||||||
|
Compiler configurations beyond that baseline is on a best-effort basis.
|
||||||
|
We strive to support recent GCC and MSVC compilers.
|
||||||
|
|
||||||
|
## Test code
|
||||||
|
|
||||||
|
We might relax the above rules rules for test code, since test code
|
||||||
|
shouldn't ship to users.
|
||||||
|
|
||||||
|
However, test code should still be readable and maintainable.
|
||||||
|
|
||||||
|
For test code, the tradeoff between readability and maintainability
|
||||||
|
and other factors is weighted even more strongly toward readability
|
||||||
|
and maintainability.
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue