Update contribution guidelines related to clang-format usage

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 08d5209e7fc9e012b22557d3a1fb7be92397ddde..475e269c717720ba2804d46d1050b957a194b581 100644 (file)
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -42,9 +42,7 @@ Here are some hints to make the process smoother:
   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/).
-* If you have [clang-format](https://clang.llvm.org/docs/ClangFormat.html) 6.0
-  or newer, you can run `make format` to adapt your modifications to ccache's
-  code style.
+* Please follow the ccache's code style (see the section below).
 * Consider [A Note About Git Commit
   Messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
   when writing commit messages.
@@ -56,19 +54,22 @@ The conversion is a slow work in progress, which is why there is a lot of
 C-style code left. Please refrain from doing large C to C++ conversions; do it
 little by little.
 
-Source code formatting is defined by `.clang-format` in the root directory.
-It's based on [LLVM's code formatting
-style](https://llvm.org/docs/CodingStandards.html) with some exceptions. You
-can install the [clang-format](https://clang.llvm.org/docs/ClangFormat.html)
-6.0 or newer and run `make format` to fix up the source code formatting.
+Source code formatting is defined by `.clang-format` in the root directory. The
+format is loosely based on [LLVM's code formatting
+style](https://llvm.org/docs/CodingStandards.html) with some exceptions. It's
+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.
 
 Please follow these conventions:
 
-* Always use curly braces around if/for/while/do bodies, even if they only
-  contain one statement.
 * Use `UpperCamelCase` for types (e.g. classes and structs) and namespaces.
 * Use `UPPER_CASE` names for macros.
 * Use `snake_case` for other names (functions, variables, enum 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.
+* Always use curly braces around if/for/while/do bodies, even if they only
+  contain one statement.