|
11 | 11 | .. _`Sphinx style guide`: https://documentation-style-guide-sphinx.readthedocs.io/en/latest/style-guide.html |
12 | 12 | .. _`PEP-8`: https://www.python.org/dev/peps/pep-0008/ |
13 | 13 | .. _`gersemi`: https://github.com/BlankSpruce/gersemi |
| 14 | +.. _`clang-tidy`: https://clang.llvm.org/extra/clang-tidy/ |
| 15 | +.. _`clang-format`: https://clang.llvm.org/docs/ClangFormat.html |
14 | 16 |
|
15 | 17 | .. targets-end-do-not-remove |
16 | 18 |
|
@@ -124,6 +126,8 @@ Build the Conda package |
124 | 126 | Contribution Guidelines |
125 | 127 | *********************** |
126 | 128 |
|
| 129 | +.. contribution-start-do-not-remove |
| 130 | +
|
127 | 131 | Git Commit Message |
128 | 132 | ================== |
129 | 133 |
|
@@ -172,41 +176,45 @@ and any automatic fixes may be reviewed and then applied by developers with the |
172 | 176 | $ gersemi CMakeLists.txt src/ docs/ --diff |
173 | 177 | $ gersemi CMakeLists.txt src/ docs/ --in-place |
174 | 178 |
|
175 | | -This project does not yet have a full style guide. Generally, wherever a style can't be inferred from surrounding code |
176 | | -this project falls back to `PEP-8`_ -like styles. There are two notable exceptions to the notional PEP-8 fall back: |
| 179 | +This project enforces its style using `clang-tidy`_ and `clang-format`_ as configured with the |
| 180 | +`.clang-format` and `.clang-tidy` files in the root directory. The formatting of the project can be |
| 181 | +checked using `clang-tidy`_ by first configuring the project using |
177 | 182 |
|
178 | | -1. `Doxygen`_ style docstrings are required for automated, API from source documentation. |
179 | | -2. This project prefers expansive whitespace surrounding parentheses, braces, and brackets. |
| 183 | +.. code-block: |
180 | 184 |
|
181 | | - * No leading space between a function and the argument list. |
182 | | - * One space following an open paranthesis ``(``, brace ``{``, or bracket ``[`` |
183 | | - * One space leading a close paranthesis ``)``, brace ``}``, or bracket ``]`` |
| 185 | + $ cmake -S . -B build ... -DCMAKE_EXPORT_COMPILE_COMMANDS=ON |
184 | 186 |
|
185 | | -An example of the whitespace style: |
| 187 | +where `...` are the other configuration flags specified. After this clang-tidy can be run on the |
| 188 | +full project from the source directory via |
186 | 189 |
|
187 | | -.. code-block:: bash |
| 190 | +.. CAUTION:: |
| 191 | + Commit all changes prior to running the clang tidy command. This will edit all source files. |
188 | 192 |
|
189 | | - my_function( arg1, { arg2, arg3 }, arg4 ); |
| 193 | +.. code-block: |
| 194 | +
|
| 195 | + $ run-clang-tidy -config-file=.clang-tidy -header-filter=*.h -p build |
190 | 196 |
|
191 | | -The following ``sed`` commands may be useful for updating white space, but must |
192 | | -be used with care. The developer is recommended to use a unique git commit |
193 | | -between each command with a corresponding review of the changes and a unit test |
194 | | -run. |
| 197 | +The formatting can be checked using `clang-format`_ by running |
195 | 198 |
|
196 | | -* Trailing space for open paren/brace/bracket |
| 199 | +.. code-block: |
197 | 200 |
|
198 | | - .. code-block:: bash |
| 201 | + $ cmake -S . -B build ... |
| 202 | + $ cmake --build build --target cpp-format-check |
199 | 203 |
|
200 | | - sed -i 's/\([({[]\)\([^ ]\)/\1 \2/g' <list of files to update> |
| 204 | +which will indicate if the formatting is correct. The c++ files can be re-formatted to match the |
| 205 | +style guidance by running |
201 | 206 |
|
202 | | -* Leading space for close paren/brace/bracket |
| 207 | +.. CAUTION:: |
| 208 | + Commit all changes prior to running the format command. This will edit all source files. |
203 | 209 |
|
204 | | - .. code-block:: bash |
| 210 | +.. code-block |
205 | 211 |
|
206 | | - sed -i 's/\([^ ]\)\([)}\]]\)/\1 \2/g' <list of files to update> |
| 212 | + $ cmake --build build --target cpp-format |
207 | 213 |
|
208 | | -* White space between adjacent paren/brace/bracket |
| 214 | +If the style is not constrained by the above, it should be inferred by the surrounding code. |
| 215 | +Wherever a style can't be inferred from surrounding code this project falls back to `PEP-8`_-like |
| 216 | +styles the exceptions to the notional PEP-8 fall back: |
209 | 217 |
|
210 | | - .. code-block:: bash |
| 218 | +1. `Doxygen`_ style docstrings are required for automated, API from source documentation. |
211 | 219 |
|
212 | | - sed -i 's/\([)}\]]\)\([)}\]]\)/\1 \2/g' <list of files to update> |
| 220 | +.. contribution-end-do-not-remove |
0 commit comments