David Neto | fae0aa6 | 2021-04-08 15:10:47 +0000 | [diff] [blame] | 1 | # Tint style guide |
| 2 | |
| 3 | * Generally, follow the [Chromium style guide for C++](https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/c++.md) |
| 4 | which itself is built on the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html). |
| 5 | |
| 6 | * Overall try to use the same style and convention as code around your change. |
| 7 | |
| 8 | * Code must be formatted. Use `clang-format` with the provided [.clang-format](../.clang-format) |
| 9 | file. The `tools/format` script runs the formatter. |
| 10 | |
| 11 | * Code should not have linting errors. |
| 12 | The `tools/lint` script runs the linter. So does `git cl upload`. |
| 13 | |
| 14 | * Do not use C++ exceptions |
| 15 | |
| 16 | * Do not use C++ RTTI. |
dan sinclair | bae54e7 | 2023-07-28 15:01:54 +0000 | [diff] [blame] | 17 | Instead, use `tint::Castable::As<T>()` from |
David Neto | fae0aa6 | 2021-04-08 15:10:47 +0000 | [diff] [blame] | 18 | [src/castable.h](../src/castable.h) |
| 19 | |
| 20 | * Generally, avoid `assert`. Instead, issue a [diagnostic](../src/diagnostic.h) |
| 21 | and fail gracefully, possibly by returning an error sentinel value. |
| 22 | Code that should not be reachable should call `TINT_UNREACHABLE` macro |
| 23 | and other internal error conditions should call the `TINT_ICE` macro. |
| 24 | See [src/debug.h](../src/debug.h) |
| 25 | |
| 26 | * Use `type` as part of a name only when the name refers to a type |
| 27 | in WGSL or another shader language processed by Tint. If the concept you are |
| 28 | trying to name is about distinguishing between alternatives, use `kind` instead. |
| 29 | |
Ben Clayton | a7230f0 | 2022-04-11 14:37:21 +0000 | [diff] [blame] | 30 | * Forward declarations: |
| 31 | * Use forward declarations where possible, instead of using `#include`'s. |
| 32 | * Place forward declarations in their own **un-nested** namespace declarations. \ |
| 33 | Example: \ |
| 34 | to forward-declare `struct X` in namespace `A` and `struct Y` |
| 35 | in namespace `A::B`, you'd write: |
| 36 | ```c++ |
| 37 | // Forward declarations |
| 38 | namespace A { |
| 39 | struct X; |
| 40 | } // namespace A |
| 41 | namespace A::B { |
| 42 | struct Y; |
| 43 | } // namespace A::B |
| 44 | |
| 45 | // rest of the header code is declared below ... |
| 46 | ``` |
| 47 | |
David Neto | fae0aa6 | 2021-04-08 15:10:47 +0000 | [diff] [blame] | 48 | ## Compiler support |
| 49 | |
dan sinclair | a9d2f63 | 2022-03-31 14:30:46 +0000 | [diff] [blame] | 50 | Tint requires C++17. |
David Neto | fae0aa6 | 2021-04-08 15:10:47 +0000 | [diff] [blame] | 51 | |
| 52 | Tint uses the Chromium build system and will stay synchronized with that system. |
| 53 | Compiler configurations beyond that baseline is on a best-effort basis. |
| 54 | We strive to support recent GCC and MSVC compilers. |
| 55 | |
| 56 | ## Test code |
| 57 | |
| 58 | We might relax the above rules rules for test code, since test code |
| 59 | shouldn't ship to users. |
| 60 | |
| 61 | However, test code should still be readable and maintainable. |
| 62 | |
| 63 | For test code, the tradeoff between readability and maintainability |
| 64 | and other factors is weighted even more strongly toward readability |
| 65 | and maintainability. |