avoid potentially wasting time on doing something that may need major rework
to be accepted, or maybe doesn't end up being accepted at all.
* Is your pull request "work in progress", i.e. you don't think that it's ready
- for merging yet but you want early comments and CI test results? Then create
- a draft pull request as described in [this Github blog
+ for merging yet but you want early comments and CI test results? Then create a
+ draft pull request as described in [this Github blog
post](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
* Please follow the ccache's code style (see the section below).
* Consider [A Note About Git Commit
highly recommended to install
[Clang-Format](https://clang.llvm.org/docs/ClangFormat.html) 6.0 or newer and
run `make format` to format changes according to ccache's code style. Or even
-better: set up your editor to run Clang-Format automatically when saving. If
-you don't run Clang-Format then the ccache authors have to do it for you.
+better: set up your editor to run Clang-Format automatically when saving. If you
+don't run Clang-Format then the ccache authors have to do it for you.
Please follow these conventions:
* Use `UpperCamelCase` for types (e.g. classes and structs) and namespaces.
* Use `UPPER_CASE` names for macros and (non-class )enum values.
-* Use `snake_case` for other names (functions, variables, enum class values, etc.).
+* Use `snake_case` for other names (functions, variables, enum class values,
+ etc.).
* Use an `m_` prefix for non-public member variables.
* Use a `g_` prefix for global mutable variables.
* Use a `k_` prefix for global constants.