3 This file is automatically generated, in part. Do not edit the style options
4 in this file directly. Instead, modify them in include/clang/Format/Format.h
5 and run the docs/tools/dump_format_style.py script to update this file.
9 <style type="text/css">
10 .versionbadge { background-color: #1c913d; height: 20px; display: inline-block; min-width: 120px; text-align: center; border-radius: 5px; color: #FFFFFF; font-family: "Verdana,Geneva,DejaVu Sans,sans-serif"; }
13 .. role:: versionbadge
15 ==========================
16 Clang-Format Style Options
17 ==========================
19 :doc:`ClangFormatStyleOptions` describes configurable formatting style options
20 supported by :doc:`LibFormat` and :doc:`ClangFormat`.
22 When using :program:`clang-format` command line utility or
23 ``clang::format::reformat(...)`` functions from code, one can either use one of
24 the predefined styles (LLVM, Google, Chromium, Mozilla, WebKit, Microsoft) or
25 create a custom style by configuring specific style options.
28 Configuring Style with clang-format
29 ===================================
31 :program:`clang-format` supports two ways to provide custom style options:
32 directly specify style configuration in the ``-style=`` command line option or
33 use ``-style=file`` and put style configuration in the ``.clang-format`` or
34 ``_clang-format`` file in the project directory.
36 When using ``-style=file``, :program:`clang-format` for each input file will
37 try to find the ``.clang-format`` file located in the closest parent directory
38 of the input file. When the standard input is used, the search is started from
39 the current directory.
41 When using ``-style=file:<format_file_path>``, :program:`clang-format` for
42 each input file will use the format file located at `<format_file_path>`.
43 The path may be absolute or relative to the working directory.
45 The ``.clang-format`` file uses YAML format:
54 The configuration file can consist of several sections each having different
55 ``Language:`` parameter denoting the programming language this section of the
56 configuration is targeted at. See the description of the **Language** option
57 below for the list of supported languages. The first section may have no
58 language set, it will set the default style options for all languages.
59 Configuration sections for specific language will override options set in the
62 When :program:`clang-format` formats a file, it auto-detects the language using
63 the file name. When formatting standard input or a file that doesn't have the
64 extension corresponding to its language, ``-assume-filename=`` option can be
65 used to override the file name :program:`clang-format` uses to detect the
68 An example of a configuration file for multiple languages:
73 # We'll use defaults from the LLVM style, but with 4 columns indentation.
78 # Force pointers to the type for C++.
79 DerivePointerAlignment: false
80 PointerAlignment: Left
83 # Use 100 columns for JS.
87 # Don't format .proto files.
91 # Use 100 columns for C#.
95 An easy way to get a valid ``.clang-format`` file containing all configuration
96 options of a certain predefined style is:
98 .. code-block:: console
100 clang-format -style=llvm -dump-config > .clang-format
102 When specifying configuration in the ``-style=`` option, the same configuration
103 is applied for all input files. The format of the configuration is:
105 .. code-block:: console
107 -style='{key1: value1, key2: value2, ...}'
110 Disabling Formatting on a Piece of Code
111 =======================================
113 Clang-format understands also special comments that switch formatting in a
114 delimited range. The code between a comment ``// clang-format off`` or
115 ``/* clang-format off */`` up to a comment ``// clang-format on`` or
116 ``/* clang-format on */`` will not be formatted. The comments themselves will be
117 formatted (aligned) normally. Also, a colon (``:``) and additional text may
118 follow ``// clang-format off`` or ``// clang-format on`` to explain why
119 clang-format is turned off or back on.
125 void unformatted_code ;
127 void formatted_code_again;
130 Configuring Style in Code
131 =========================
133 When using ``clang::format::reformat(...)`` functions, the format is specified
134 by supplying the `clang::format::FormatStyle
135 <https://clang.llvm.org/doxygen/structclang_1_1format_1_1FormatStyle.html>`_
139 Configurable Format Style Options
140 =================================
142 This section lists the supported style options. Value type is specified for
143 each option. For enumeration types possible values are specified both as a C++
144 enumeration member (with a prefix, e.g. ``LS_Auto``), and as a value usable in
145 the configuration (without a prefix: ``Auto``).
149 **BasedOnStyle** (``String``) :ref:`¶ <BasedOnStyle>`
150 The style used for all options not specifically set in the configuration.
152 This option is supported only in the :program:`clang-format` configuration
153 (both within ``-style='{...}'`` and the ``.clang-format`` file).
158 A style complying with the `LLVM coding standards
159 <https://llvm.org/docs/CodingStandards.html>`_
161 A style complying with `Google's C++ style guide
162 <https://google.github.io/styleguide/cppguide.html>`_
164 A style complying with `Chromium's style guide
165 <https://chromium.googlesource.com/chromium/src/+/refs/heads/main/styleguide/styleguide.md>`_
167 A style complying with `Mozilla's style guide
168 <https://firefox-source-docs.mozilla.org/code-quality/coding-style/index.html>`_
170 A style complying with `WebKit's style guide
171 <https://www.webkit.org/coding/coding-style.html>`_
173 A style complying with `Microsoft's style guide
174 <https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference>`_
176 A style complying with the `GNU coding standards
177 <https://www.gnu.org/prep/standards/standards.html>`_
178 * ``InheritParentConfig``
179 Not a real style, but allows to use the ``.clang-format`` file from the
180 parent directory (or its parent if there is none). If there is no parent
181 file found it falls back to the ``fallback`` style, and applies the changes
184 With this option you can overwrite some parts of your main style for your
185 subdirectories. This is also possible through the command line, e.g.:
186 ``--style={BasedOnStyle: InheritParentConfig, ColumnLimit: 20}``
188 .. START_FORMAT_STYLE_OPTIONS
190 .. _AccessModifierOffset:
192 **AccessModifierOffset** (``Integer``) :versionbadge:`clang-format 3.3` :ref:`¶ <AccessModifierOffset>`
193 The extra indent or outdent of access modifiers, e.g. ``public:``.
195 .. _AlignAfterOpenBracket:
197 **AlignAfterOpenBracket** (``BracketAlignmentStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignAfterOpenBracket>`
198 If ``true``, horizontally aligns arguments after an open bracket.
200 This applies to round brackets (parentheses), angle brackets and square
205 * ``BAS_Align`` (in configuration: ``Align``)
206 Align parameters on the open bracket, e.g.:
210 someLongFunction(argument1,
213 * ``BAS_DontAlign`` (in configuration: ``DontAlign``)
214 Don't align, instead use ``ContinuationIndentWidth``, e.g.:
218 someLongFunction(argument1,
221 * ``BAS_AlwaysBreak`` (in configuration: ``AlwaysBreak``)
222 Always break after an open bracket, if the parameters don't fit
223 on a single line, e.g.:
228 argument1, argument2);
230 * ``BAS_BlockIndent`` (in configuration: ``BlockIndent``)
231 Always break after an open bracket, if the parameters don't fit
232 on a single line. Closing brackets will be placed on a new line.
244 This currently only applies to braced initializer lists (when
245 ``Cpp11BracedListStyle`` is ``true``) and parentheses.
249 .. _AlignArrayOfStructures:
251 **AlignArrayOfStructures** (``ArrayInitializerAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ <AlignArrayOfStructures>`
252 If not ``None``, when using initialization for an array of structs
253 aligns the fields into columns.
258 As of clang-format 15 this option only applied to arrays with equal
259 number of columns per row.
263 * ``AIAS_Left`` (in configuration: ``Left``)
264 Align array column and left justify the columns e.g.:
271 {-1, 93463, "world"},
275 * ``AIAS_Right`` (in configuration: ``Right``)
276 Align array column and right justify the columns e.g.:
283 {-1, 93463, "world"},
287 * ``AIAS_None`` (in configuration: ``None``)
288 Don't align array initializer columns.
292 .. _AlignConsecutiveAssignments:
294 **AlignConsecutiveAssignments** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignConsecutiveAssignments>`
295 Style of aligning consecutive assignments.
297 ``Consecutive`` will result in formattings like:
302 int somelongname = 2;
305 Nested configuration flags:
309 They can also be read as a whole for compatibility. The choices are:
313 * ``AcrossEmptyLines``
315 * ``AcrossEmptyLinesAndComments``
317 For example, to align across empty lines and not across comments, either
322 AlignConsecutiveAssignments: AcrossEmptyLines
324 AlignConsecutiveAssignments:
326 AcrossEmptyLines: true
327 AcrossComments: false
329 * ``bool Enabled`` Whether aligning is enabled.
333 #define SHORT_NAME 42
334 #define LONGER_NAME 0x007f
335 #define EVEN_LONGER_NAME (2)
336 #define foo(x) (x * x)
337 #define bar(y, z) (y + z)
340 int somelongname = 2;
351 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
357 int somelongname = 2;
364 int somelongname = 2;
369 * ``bool AcrossComments`` Whether to align across comments.
383 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
384 like ``+=`` are aligned along with ``=``.
396 * ``bool AlignFunctionDeclarations`` Only for ``AlignConsecutiveDeclarations``. Whether function declarations
402 unsigned int f1(void);
407 unsigned int f1(void);
411 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
428 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
429 operators are left-padded to the same length as long ones in order to
430 put all assignment operators to the right of the left hand side.
449 .. _AlignConsecutiveBitFields:
451 **AlignConsecutiveBitFields** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 11` :ref:`¶ <AlignConsecutiveBitFields>`
452 Style of aligning consecutive bit fields.
454 ``Consecutive`` will align the bitfield separators of consecutive lines.
455 This will result in formattings like:
463 Nested configuration flags:
467 They can also be read as a whole for compatibility. The choices are:
471 * ``AcrossEmptyLines``
473 * ``AcrossEmptyLinesAndComments``
475 For example, to align across empty lines and not across comments, either
480 AlignConsecutiveBitFields: AcrossEmptyLines
482 AlignConsecutiveBitFields:
484 AcrossEmptyLines: true
485 AcrossComments: false
487 * ``bool Enabled`` Whether aligning is enabled.
491 #define SHORT_NAME 42
492 #define LONGER_NAME 0x007f
493 #define EVEN_LONGER_NAME (2)
494 #define foo(x) (x * x)
495 #define bar(y, z) (y + z)
498 int somelongname = 2;
509 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
515 int somelongname = 2;
522 int somelongname = 2;
527 * ``bool AcrossComments`` Whether to align across comments.
541 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
542 like ``+=`` are aligned along with ``=``.
554 * ``bool AlignFunctionDeclarations`` Only for ``AlignConsecutiveDeclarations``. Whether function declarations
560 unsigned int f1(void);
565 unsigned int f1(void);
569 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
586 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
587 operators are left-padded to the same length as long ones in order to
588 put all assignment operators to the right of the left hand side.
607 .. _AlignConsecutiveDeclarations:
609 **AlignConsecutiveDeclarations** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignConsecutiveDeclarations>`
610 Style of aligning consecutive declarations.
612 ``Consecutive`` will align the declaration names of consecutive lines.
613 This will result in formattings like:
621 Nested configuration flags:
625 They can also be read as a whole for compatibility. The choices are:
629 * ``AcrossEmptyLines``
631 * ``AcrossEmptyLinesAndComments``
633 For example, to align across empty lines and not across comments, either
638 AlignConsecutiveDeclarations: AcrossEmptyLines
640 AlignConsecutiveDeclarations:
642 AcrossEmptyLines: true
643 AcrossComments: false
645 * ``bool Enabled`` Whether aligning is enabled.
649 #define SHORT_NAME 42
650 #define LONGER_NAME 0x007f
651 #define EVEN_LONGER_NAME (2)
652 #define foo(x) (x * x)
653 #define bar(y, z) (y + z)
656 int somelongname = 2;
667 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
673 int somelongname = 2;
680 int somelongname = 2;
685 * ``bool AcrossComments`` Whether to align across comments.
699 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
700 like ``+=`` are aligned along with ``=``.
712 * ``bool AlignFunctionDeclarations`` Only for ``AlignConsecutiveDeclarations``. Whether function declarations
718 unsigned int f1(void);
723 unsigned int f1(void);
727 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
744 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
745 operators are left-padded to the same length as long ones in order to
746 put all assignment operators to the right of the left hand side.
765 .. _AlignConsecutiveMacros:
767 **AlignConsecutiveMacros** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AlignConsecutiveMacros>`
768 Style of aligning consecutive macro definitions.
770 ``Consecutive`` will result in formattings like:
774 #define SHORT_NAME 42
775 #define LONGER_NAME 0x007f
776 #define EVEN_LONGER_NAME (2)
777 #define foo(x) (x * x)
778 #define bar(y, z) (y + z)
780 Nested configuration flags:
784 They can also be read as a whole for compatibility. The choices are:
788 * ``AcrossEmptyLines``
790 * ``AcrossEmptyLinesAndComments``
792 For example, to align across empty lines and not across comments, either
797 AlignConsecutiveMacros: AcrossEmptyLines
799 AlignConsecutiveMacros:
801 AcrossEmptyLines: true
802 AcrossComments: false
804 * ``bool Enabled`` Whether aligning is enabled.
808 #define SHORT_NAME 42
809 #define LONGER_NAME 0x007f
810 #define EVEN_LONGER_NAME (2)
811 #define foo(x) (x * x)
812 #define bar(y, z) (y + z)
815 int somelongname = 2;
826 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
832 int somelongname = 2;
839 int somelongname = 2;
844 * ``bool AcrossComments`` Whether to align across comments.
858 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
859 like ``+=`` are aligned along with ``=``.
871 * ``bool AlignFunctionDeclarations`` Only for ``AlignConsecutiveDeclarations``. Whether function declarations
877 unsigned int f1(void);
882 unsigned int f1(void);
886 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
903 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
904 operators are left-padded to the same length as long ones in order to
905 put all assignment operators to the right of the left hand side.
924 .. _AlignConsecutiveShortCaseStatements:
926 **AlignConsecutiveShortCaseStatements** (``ShortCaseStatementsAlignmentStyle``) :versionbadge:`clang-format 17` :ref:`¶ <AlignConsecutiveShortCaseStatements>`
927 Style of aligning consecutive short case labels.
928 Only applies if ``AllowShortCaseExpressionOnASingleLine`` or
929 ``AllowShortCaseLabelsOnASingleLine`` is ``true``.
935 AlignConsecutiveShortCaseStatements:
937 AcrossEmptyLines: true
939 AlignCaseColons: false
941 Nested configuration flags:
945 * ``bool Enabled`` Whether aligning is enabled.
951 case log::info: return "info:";
952 case log::warning: return "warning:";
958 case log::info: return "info:";
959 case log::warning: return "warning:";
963 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
969 case log::info: return "info:";
970 case log::warning: return "warning:";
977 case log::info: return "info:";
978 case log::warning: return "warning:";
983 * ``bool AcrossComments`` Whether to align across comments.
989 case log::info: return "info:";
990 case log::warning: return "warning:";
997 case log::info: return "info:";
998 case log::warning: return "warning:";
1003 * ``bool AlignCaseArrows`` Whether to align the case arrows when aligning short case expressions.
1005 .. code-block:: java
1009 case THURSDAY, SATURDAY -> 8;
1010 case WEDNESDAY -> 9;
1016 case THURSDAY, SATURDAY -> 8;
1017 case WEDNESDAY -> 9;
1021 * ``bool AlignCaseColons`` Whether aligned case labels are aligned on the colon, or on the tokens
1028 case log::info : return "info:";
1029 case log::warning: return "warning:";
1030 default : return "";
1035 case log::info: return "info:";
1036 case log::warning: return "warning:";
1041 .. _AlignConsecutiveTableGenBreakingDAGArgColons:
1043 **AlignConsecutiveTableGenBreakingDAGArgColons** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 19` :ref:`¶ <AlignConsecutiveTableGenBreakingDAGArgColons>`
1044 Style of aligning consecutive TableGen DAGArg operator colons.
1045 If enabled, align the colon inside DAGArg which have line break inside.
1046 This works only when TableGenBreakInsideDAGArg is BreakElements or
1047 BreakAll and the DAGArg is not excepted by
1048 TableGenBreakingDAGArgOperators's effect.
1058 Nested configuration flags:
1062 They can also be read as a whole for compatibility. The choices are:
1066 * ``AcrossEmptyLines``
1067 * ``AcrossComments``
1068 * ``AcrossEmptyLinesAndComments``
1070 For example, to align across empty lines and not across comments, either
1075 AlignConsecutiveTableGenBreakingDAGArgColons: AcrossEmptyLines
1077 AlignConsecutiveTableGenBreakingDAGArgColons:
1079 AcrossEmptyLines: true
1080 AcrossComments: false
1082 * ``bool Enabled`` Whether aligning is enabled.
1086 #define SHORT_NAME 42
1087 #define LONGER_NAME 0x007f
1088 #define EVEN_LONGER_NAME (2)
1089 #define foo(x) (x * x)
1090 #define bar(y, z) (y + z)
1093 int somelongname = 2;
1104 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
1110 int somelongname = 2;
1117 int somelongname = 2;
1122 * ``bool AcrossComments`` Whether to align across comments.
1136 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
1137 like ``+=`` are aligned along with ``=``.
1149 * ``bool AlignFunctionDeclarations`` Only for ``AlignConsecutiveDeclarations``. Whether function declarations
1155 unsigned int f1(void);
1160 unsigned int f1(void);
1164 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
1181 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
1182 operators are left-padded to the same length as long ones in order to
1183 put all assignment operators to the right of the left hand side.
1202 .. _AlignConsecutiveTableGenCondOperatorColons:
1204 **AlignConsecutiveTableGenCondOperatorColons** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 19` :ref:`¶ <AlignConsecutiveTableGenCondOperatorColons>`
1205 Style of aligning consecutive TableGen cond operator colons.
1206 Align the colons of cases inside !cond operators.
1210 !cond(!eq(size, 1) : 1,
1214 Nested configuration flags:
1218 They can also be read as a whole for compatibility. The choices are:
1222 * ``AcrossEmptyLines``
1223 * ``AcrossComments``
1224 * ``AcrossEmptyLinesAndComments``
1226 For example, to align across empty lines and not across comments, either
1231 AlignConsecutiveTableGenCondOperatorColons: AcrossEmptyLines
1233 AlignConsecutiveTableGenCondOperatorColons:
1235 AcrossEmptyLines: true
1236 AcrossComments: false
1238 * ``bool Enabled`` Whether aligning is enabled.
1242 #define SHORT_NAME 42
1243 #define LONGER_NAME 0x007f
1244 #define EVEN_LONGER_NAME (2)
1245 #define foo(x) (x * x)
1246 #define bar(y, z) (y + z)
1249 int somelongname = 2;
1260 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
1266 int somelongname = 2;
1273 int somelongname = 2;
1278 * ``bool AcrossComments`` Whether to align across comments.
1292 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
1293 like ``+=`` are aligned along with ``=``.
1305 * ``bool AlignFunctionDeclarations`` Only for ``AlignConsecutiveDeclarations``. Whether function declarations
1311 unsigned int f1(void);
1316 unsigned int f1(void);
1320 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
1337 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
1338 operators are left-padded to the same length as long ones in order to
1339 put all assignment operators to the right of the left hand side.
1358 .. _AlignConsecutiveTableGenDefinitionColons:
1360 **AlignConsecutiveTableGenDefinitionColons** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 19` :ref:`¶ <AlignConsecutiveTableGenDefinitionColons>`
1361 Style of aligning consecutive TableGen definition colons.
1362 This aligns the inheritance colons of consecutive definitions.
1367 def DefDef : Parent {}
1368 def DefDefDef : Parent {}
1370 Nested configuration flags:
1374 They can also be read as a whole for compatibility. The choices are:
1378 * ``AcrossEmptyLines``
1379 * ``AcrossComments``
1380 * ``AcrossEmptyLinesAndComments``
1382 For example, to align across empty lines and not across comments, either
1387 AlignConsecutiveTableGenDefinitionColons: AcrossEmptyLines
1389 AlignConsecutiveTableGenDefinitionColons:
1391 AcrossEmptyLines: true
1392 AcrossComments: false
1394 * ``bool Enabled`` Whether aligning is enabled.
1398 #define SHORT_NAME 42
1399 #define LONGER_NAME 0x007f
1400 #define EVEN_LONGER_NAME (2)
1401 #define foo(x) (x * x)
1402 #define bar(y, z) (y + z)
1405 int somelongname = 2;
1416 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
1422 int somelongname = 2;
1429 int somelongname = 2;
1434 * ``bool AcrossComments`` Whether to align across comments.
1448 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
1449 like ``+=`` are aligned along with ``=``.
1461 * ``bool AlignFunctionDeclarations`` Only for ``AlignConsecutiveDeclarations``. Whether function declarations
1467 unsigned int f1(void);
1472 unsigned int f1(void);
1476 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
1493 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
1494 operators are left-padded to the same length as long ones in order to
1495 put all assignment operators to the right of the left hand side.
1514 .. _AlignEscapedNewlines:
1516 **AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) :versionbadge:`clang-format 5` :ref:`¶ <AlignEscapedNewlines>`
1517 Options for aligning backslashes in escaped newlines.
1521 * ``ENAS_DontAlign`` (in configuration: ``DontAlign``)
1522 Don't align escaped newlines.
1531 * ``ENAS_Left`` (in configuration: ``Left``)
1532 Align escaped newlines as far left as possible.
1541 * ``ENAS_LeftWithLastLine`` (in configuration: ``LeftWithLastLine``)
1542 Align escaped newlines as far left as possible, using the last line of
1543 the preprocessor directive as the reference if it's the longest.
1552 * ``ENAS_Right`` (in configuration: ``Right``)
1553 Align escaped newlines in the right-most column.
1566 **AlignOperands** (``OperandAlignmentStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AlignOperands>`
1567 If ``true``, horizontally align operands of binary and ternary
1572 * ``OAS_DontAlign`` (in configuration: ``DontAlign``)
1573 Do not align operands of binary and ternary expressions.
1574 The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
1575 the start of the line.
1577 * ``OAS_Align`` (in configuration: ``Align``)
1578 Horizontally align operands of binary and ternary expressions.
1580 Specifically, this aligns operands of a single expression that needs
1581 to be split over multiple lines, e.g.:
1585 int aaa = bbbbbbbbbbbbbbb +
1588 When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
1589 aligned with the operand on the first line.
1593 int aaa = bbbbbbbbbbbbbbb
1596 * ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
1597 Horizontally align operands of binary and ternary expressions.
1599 This is similar to ``OAS_Align``, except when
1600 ``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
1601 that the wrapped operand is aligned with the operand on the first line.
1605 int aaa = bbbbbbbbbbbbbbb
1610 .. _AlignTrailingComments:
1612 **AlignTrailingComments** (``TrailingCommentsAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlignTrailingComments>`
1613 Control of trailing comments.
1615 The alignment stops at closing braces after a line break, and only
1616 followed by other closing braces, a (``do-``) ``while``, a lambda call, or
1622 As of clang-format 16 this option is not a bool but can be set
1623 to the options. Conventional bool options still can be parsed as before.
1626 .. code-block:: yaml
1629 AlignTrailingComments:
1633 Nested configuration flags:
1637 * ``TrailingCommentsAlignmentKinds Kind``
1638 Specifies the way to align trailing comments.
1642 * ``TCAS_Leave`` (in configuration: ``Leave``)
1643 Leave trailing comments as they are.
1651 int abcd; // comment
1653 * ``TCAS_Always`` (in configuration: ``Always``)
1654 Align trailing comments.
1662 int abcd; // comment
1664 * ``TCAS_Never`` (in configuration: ``Never``)
1665 Don't align trailing comments but other formatter applies.
1673 int abcd; // comment
1676 * ``unsigned OverEmptyLines`` How many empty lines to apply alignment.
1677 When both ``MaxEmptyLinesToKeep`` and ``OverEmptyLines`` are set to 2,
1678 it formats like below.
1684 int ab; // comments are
1687 int abcdef; // aligned
1689 When ``MaxEmptyLinesToKeep`` is set to 2 and ``OverEmptyLines`` is set
1690 to 1, it formats like below.
1699 int abcdef; // but this isn't
1702 .. _AllowAllArgumentsOnNextLine:
1704 **AllowAllArgumentsOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllArgumentsOnNextLine>`
1705 If a function call or braced initializer list doesn't fit on a
1706 line, allow putting all arguments onto the next line, even if
1707 ``BinPackArguments`` is ``false``.
1721 .. _AllowAllConstructorInitializersOnNextLine:
1723 **AllowAllConstructorInitializersOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllConstructorInitializersOnNextLine>`
1724 This option is **deprecated**. See ``NextLine`` of
1725 ``PackConstructorInitializers``.
1727 .. _AllowAllParametersOfDeclarationOnNextLine:
1729 **AllowAllParametersOfDeclarationOnNextLine** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowAllParametersOfDeclarationOnNextLine>`
1730 If the function declaration doesn't fit on a line,
1731 allow putting all parameters of a function declaration onto
1732 the next line even if ``BinPackParameters`` is ``OnePerLine``.
1738 int a, int b, int c, int d, int e);
1741 void myFunction(int a,
1747 .. _AllowBreakBeforeNoexceptSpecifier:
1749 **AllowBreakBeforeNoexceptSpecifier** (``BreakBeforeNoexceptSpecifierStyle``) :versionbadge:`clang-format 18` :ref:`¶ <AllowBreakBeforeNoexceptSpecifier>`
1750 Controls if there could be a line break before a ``noexcept`` specifier.
1754 * ``BBNSS_Never`` (in configuration: ``Never``)
1755 No line break allowed.
1760 double arg2) noexcept;
1762 void bar(int arg1, double arg2) noexcept(
1763 noexcept(baz(arg1)) &&
1764 noexcept(baz(arg2)));
1766 * ``BBNSS_OnlyWithParen`` (in configuration: ``OnlyWithParen``)
1767 For a simple ``noexcept`` there is no line break allowed, but when we
1768 have a condition it is.
1773 double arg2) noexcept;
1775 void bar(int arg1, double arg2)
1776 noexcept(noexcept(baz(arg1)) &&
1777 noexcept(baz(arg2)));
1779 * ``BBNSS_Always`` (in configuration: ``Always``)
1780 Line breaks are allowed. But note that because of the associated
1781 penalties ``clang-format`` often prefers not to break before the
1787 double arg2) noexcept;
1789 void bar(int arg1, double arg2)
1790 noexcept(noexcept(baz(arg1)) &&
1791 noexcept(baz(arg2)));
1795 .. _AllowShortBlocksOnASingleLine:
1797 **AllowShortBlocksOnASingleLine** (``ShortBlockStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortBlocksOnASingleLine>`
1798 Dependent on the value, ``while (true) { continue; }`` can be put on a
1803 * ``SBS_Never`` (in configuration: ``Never``)
1804 Never merge blocks into a single line.
1814 * ``SBS_Empty`` (in configuration: ``Empty``)
1815 Only merge empty blocks.
1824 * ``SBS_Always`` (in configuration: ``Always``)
1825 Always merge short blocks into a single line.
1830 while (true) { continue; }
1834 .. _AllowShortCaseExpressionOnASingleLine:
1836 **AllowShortCaseExpressionOnASingleLine** (``Boolean``) :versionbadge:`clang-format 19` :ref:`¶ <AllowShortCaseExpressionOnASingleLine>`
1837 Whether to merge a short switch labeled rule into a single line.
1839 .. code-block:: java
1842 switch (a) { vs. switch (a) {
1843 case 1 -> 1; case 1 ->
1849 .. _AllowShortCaseLabelsOnASingleLine:
1851 **AllowShortCaseLabelsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.6` :ref:`¶ <AllowShortCaseLabelsOnASingleLine>`
1852 If ``true``, short case labels will be contracted to a single line.
1857 switch (a) { vs. switch (a) {
1858 case 1: x = 1; break; case 1:
1859 case 2: return; x = 1;
1865 .. _AllowShortCompoundRequirementOnASingleLine:
1867 **AllowShortCompoundRequirementOnASingleLine** (``Boolean``) :versionbadge:`clang-format 18` :ref:`¶ <AllowShortCompoundRequirementOnASingleLine>`
1868 Allow short compound requirement on a single line.
1873 template <typename T>
1874 concept c = requires(T x) {
1875 { x + 1 } -> std::same_as<int>;
1879 template <typename T>
1880 concept c = requires(T x) {
1883 } -> std::same_as<int>;
1886 .. _AllowShortEnumsOnASingleLine:
1888 **AllowShortEnumsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <AllowShortEnumsOnASingleLine>`
1889 Allow short enums on a single line.
1894 enum { A, B } myEnum;
1902 .. _AllowShortFunctionsOnASingleLine:
1904 **AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortFunctionsOnASingleLine>`
1905 Dependent on the value, ``int f() { return 0; }`` can be put on a
1910 * ``SFS_None`` (in configuration: ``None``)
1911 Never merge functions into a single line.
1913 * ``SFS_InlineOnly`` (in configuration: ``InlineOnly``)
1914 Only merge functions defined inside a class. Same as ``inline``,
1915 except it does not implies ``empty``: i.e. top level empty functions
1916 are not merged either.
1929 * ``SFS_Empty`` (in configuration: ``Empty``)
1930 Only merge empty functions.
1939 * ``SFS_Inline`` (in configuration: ``Inline``)
1940 Only merge functions defined inside a class. Implies ``empty``.
1952 * ``SFS_All`` (in configuration: ``All``)
1953 Merge all functions fitting on a single line.
1964 .. _AllowShortIfStatementsOnASingleLine:
1966 **AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowShortIfStatementsOnASingleLine>`
1967 Dependent on the value, ``if (a) return;`` can be put on a single line.
1971 * ``SIS_Never`` (in configuration: ``Never``)
1972 Never put short ifs on the same line.
1990 * ``SIS_WithoutElse`` (in configuration: ``WithoutElse``)
1991 Put short ifs on the same line only if there is no else statement.
2008 * ``SIS_OnlyFirstIf`` (in configuration: ``OnlyFirstIf``)
2009 Put short ifs, but not else ifs nor else statements, on the same line.
2026 * ``SIS_AllIfsAndElse`` (in configuration: ``AllIfsAndElse``)
2027 Always put short ifs, else ifs and else statements on the same
2044 .. _AllowShortLambdasOnASingleLine:
2046 **AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AllowShortLambdasOnASingleLine>`
2047 Dependent on the value, ``auto lambda []() { return 0; }`` can be put on a
2052 * ``SLS_None`` (in configuration: ``None``)
2053 Never merge lambdas into a single line.
2055 * ``SLS_Empty`` (in configuration: ``Empty``)
2056 Only merge empty lambdas.
2060 auto lambda = [](int a) {};
2061 auto lambda2 = [](int a) {
2065 * ``SLS_Inline`` (in configuration: ``Inline``)
2066 Merge lambda into a single line if the lambda is argument of a function.
2070 auto lambda = [](int x, int y) {
2073 sort(a.begin(), a.end(), [](int x, int y) { return x < y; });
2075 * ``SLS_All`` (in configuration: ``All``)
2076 Merge all lambdas fitting on a single line.
2080 auto lambda = [](int a) {};
2081 auto lambda2 = [](int a) { return a; };
2085 .. _AllowShortLoopsOnASingleLine:
2087 **AllowShortLoopsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <AllowShortLoopsOnASingleLine>`
2088 If ``true``, ``while (true) continue;`` can be put on a single
2091 .. _AlwaysBreakAfterDefinitionReturnType:
2093 **AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlwaysBreakAfterDefinitionReturnType>`
2094 The function definition return type breaking style to use. This
2095 option is **deprecated** and is retained for backwards compatibility.
2099 * ``DRTBS_None`` (in configuration: ``None``)
2100 Break after return type automatically.
2101 ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
2103 * ``DRTBS_All`` (in configuration: ``All``)
2104 Always break after the return type.
2106 * ``DRTBS_TopLevel`` (in configuration: ``TopLevel``)
2107 Always break after the return types of top-level functions.
2111 .. _AlwaysBreakAfterReturnType:
2113 **AlwaysBreakAfterReturnType** (``deprecated``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlwaysBreakAfterReturnType>`
2114 This option is renamed to ``BreakAfterReturnType``.
2116 .. _AlwaysBreakBeforeMultilineStrings:
2118 **AlwaysBreakBeforeMultilineStrings** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakBeforeMultilineStrings>`
2119 If ``true``, always break before multiline string literals.
2121 This flag is mean to make cases where there are multiple multiline strings
2122 in a file look more consistent. Thus, it will only take effect if wrapping
2123 the string at that point leads to it being indented
2124 ``ContinuationIndentWidth`` spaces from the start of the line.
2129 aaaa = vs. aaaa = "bbbb"
2133 .. _AlwaysBreakTemplateDeclarations:
2135 **AlwaysBreakTemplateDeclarations** (``deprecated``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakTemplateDeclarations>`
2136 This option is renamed to ``BreakTemplateDeclarations``.
2138 .. _AttributeMacros:
2140 **AttributeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <AttributeMacros>`
2141 A vector of strings that should be interpreted as attributes/qualifiers
2142 instead of identifiers. This can be useful for language extensions or
2143 static analyzer annotations.
2149 x = (char *__capability)&y;
2150 int function(void) __unused;
2151 void only_writes_to_buffer(char *__output buffer);
2153 In the .clang-format configuration file, this can be configured like:
2155 .. code-block:: yaml
2157 AttributeMacros: [__capability, __output, __unused]
2159 .. _BinPackArguments:
2161 **BinPackArguments** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackArguments>`
2162 If ``false``, a function call's arguments will either be all on the
2163 same line or will have one line each.
2169 f(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa,
2170 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
2175 f(aaaaaaaaaaaaaaaaaaaa,
2176 aaaaaaaaaaaaaaaaaaaa,
2177 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
2180 .. _BinPackParameters:
2182 **BinPackParameters** (``BinPackParametersStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackParameters>`
2183 The bin pack parameters style to use.
2187 * ``BPPS_BinPack`` (in configuration: ``BinPack``)
2188 Bin-pack parameters.
2192 void f(int a, int bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
2193 int ccccccccccccccccccccccccccccccccccccccccccc);
2195 * ``BPPS_OnePerLine`` (in configuration: ``OnePerLine``)
2196 Put all parameters on the current line if they fit.
2197 Otherwise, put each one on its own line.
2201 void f(int a, int b, int c);
2205 int ccccccccccccccccccccccccccccccccccccc);
2207 * ``BPPS_AlwaysOnePerLine`` (in configuration: ``AlwaysOnePerLine``)
2208 Always put each parameter on its own line.
2218 .. _BitFieldColonSpacing:
2220 **BitFieldColonSpacing** (``BitFieldColonSpacingStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BitFieldColonSpacing>`
2221 The BitFieldColonSpacingStyle to use for bitfields.
2225 * ``BFCS_Both`` (in configuration: ``Both``)
2226 Add one space on each side of the ``:``
2232 * ``BFCS_None`` (in configuration: ``None``)
2233 Add no space around the ``:`` (except when needed for
2234 ``AlignConsecutiveBitFields``).
2240 * ``BFCS_Before`` (in configuration: ``Before``)
2241 Add space before the ``:`` only
2247 * ``BFCS_After`` (in configuration: ``After``)
2248 Add space after the ``:`` only (space may be added before if
2249 needed for ``AlignConsecutiveBitFields``).
2259 **BraceWrapping** (``BraceWrappingFlags``) :versionbadge:`clang-format 3.8` :ref:`¶ <BraceWrapping>`
2260 Control of individual brace wrapping cases.
2262 If ``BreakBeforeBraces`` is set to ``Custom``, use this to specify how
2263 each individual brace case should be handled. Otherwise, this is ignored.
2265 .. code-block:: yaml
2268 BreakBeforeBraces: Custom
2272 SplitEmptyFunction: false
2274 Nested configuration flags:
2276 Precise control over the wrapping of braces.
2280 # Should be declared this way:
2281 BreakBeforeBraces: Custom
2285 * ``bool AfterCaseLabel`` Wrap case labels.
2290 switch (foo) { vs. switch (foo) {
2302 * ``bool AfterClass`` Wrap class definitions.
2313 * ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
2314 Wrap control statements (``if``/``for``/``while``/``switch``/..).
2318 * ``BWACS_Never`` (in configuration: ``Never``)
2319 Never wrap braces after a control statement.
2326 for (int i = 0; i < 10; ++i) {
2329 * ``BWACS_MultiLine`` (in configuration: ``MultiLine``)
2330 Only wrap braces after a multi-line control statement.
2339 while (foo || bar) {
2342 * ``BWACS_Always`` (in configuration: ``Always``)
2343 Always wrap braces after a control statement.
2351 for (int i = 0; i < 10; ++i)
2355 * ``bool AfterEnum`` Wrap enum definitions.
2368 * ``bool AfterFunction`` Wrap function definitions.
2385 * ``bool AfterNamespace`` Wrap namespace definitions.
2402 * ``bool AfterObjCDeclaration`` Wrap ObjC definitions (interfaces, implementations...).
2406 @autoreleasepool and @synchronized blocks are wrapped
2407 according to ``AfterControlStatement`` flag.
2409 * ``bool AfterStruct`` Wrap struct definitions.
2424 * ``bool AfterUnion`` Wrap union definitions.
2439 * ``bool AfterExternBlock`` Wrap extern blocks.
2454 * ``bool BeforeCatch`` Wrap before ``catch``.
2471 * ``bool BeforeElse`` Wrap before ``else``.
2486 * ``bool BeforeLambdaBody`` Wrap lambda block.
2504 * ``bool BeforeWhile`` Wrap before ``while``.
2519 * ``bool IndentBraces`` Indent the wrapped braces themselves.
2521 * ``bool SplitEmptyFunction`` If ``false``, empty function body can be put on a single line.
2522 This option is used only if the opening brace of the function has
2523 already been wrapped, i.e. the ``AfterFunction`` brace wrapping mode is
2524 set, and the function could/should not be put on a single line (as per
2525 ``AllowShortFunctionsOnASingleLine`` and constructor formatting
2535 * ``bool SplitEmptyRecord`` If ``false``, empty record (e.g. class, struct or union) body
2536 can be put on a single line. This option is used only if the opening
2537 brace of the record has already been wrapped, i.e. the ``AfterClass``
2538 (for classes) brace wrapping mode is set.
2543 class Foo vs. class Foo
2547 * ``bool SplitEmptyNamespace`` If ``false``, empty namespace body can be put on a single line.
2548 This option is used only if the opening brace of the namespace has
2549 already been wrapped, i.e. the ``AfterNamespace`` brace wrapping mode is
2555 namespace Foo vs. namespace Foo
2560 .. _BracedInitializerIndentWidth:
2562 **BracedInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 17` :ref:`¶ <BracedInitializerIndentWidth>`
2563 The number of columns to use to indent the contents of braced init lists.
2564 If unset, ``ContinuationIndentWidth`` is used.
2568 AlignAfterOpenBracket: AlwaysBreak
2569 BracedInitializerIndentWidth: 2
2577 auto s = SomeStruct{
2595 .. _BreakAdjacentStringLiterals:
2597 **BreakAdjacentStringLiterals** (``Boolean``) :versionbadge:`clang-format 18` :ref:`¶ <BreakAdjacentStringLiterals>`
2598 Break between adjacent string literals.
2608 return "Code" "\0\52\26\55\55\0" "x013" "\02\xBA";
2610 .. _BreakAfterAttributes:
2612 **BreakAfterAttributes** (``AttributeBreakingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakAfterAttributes>`
2613 Break after a group of C++11 attributes before variable or function
2614 (including constructor/destructor) declaration/definition names or before
2615 control statements, i.e. ``if``, ``switch`` (including ``case`` and
2616 ``default`` labels), ``for``, and ``while`` statements.
2620 * ``ABS_Always`` (in configuration: ``Always``)
2621 Always break after attributes.
2627 [[gnu::const]] [[maybe_unused]]
2632 [[gnu::const]] [[nodiscard]]
2651 * ``ABS_Leave`` (in configuration: ``Leave``)
2652 Leave the line breaking after attributes as is.
2656 [[maybe_unused]] const int i;
2657 [[gnu::const]] [[maybe_unused]]
2660 [[nodiscard]] inline int f();
2661 [[gnu::const]] [[nodiscard]]
2670 [[unlikely]] case 1:
2678 * ``ABS_Never`` (in configuration: ``Never``)
2679 Never break after attributes.
2683 [[maybe_unused]] const int i;
2684 [[gnu::const]] [[maybe_unused]] int j;
2686 [[nodiscard]] inline int f();
2687 [[gnu::const]] [[nodiscard]] int g();
2695 [[unlikely]] case 1:
2704 .. _BreakAfterJavaFieldAnnotations:
2706 **BreakAfterJavaFieldAnnotations** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ <BreakAfterJavaFieldAnnotations>`
2707 Break after each annotation on a field in Java files.
2709 .. code-block:: java
2712 @Partial vs. @Partial @Mock DataLoad loader;
2716 .. _BreakAfterReturnType:
2718 **BreakAfterReturnType** (``ReturnTypeBreakingStyle``) :versionbadge:`clang-format 19` :ref:`¶ <BreakAfterReturnType>`
2719 The function declaration return type breaking style to use.
2723 * ``RTBS_None`` (in configuration: ``None``)
2724 This is **deprecated**. See ``Automatic`` below.
2726 * ``RTBS_Automatic`` (in configuration: ``Automatic``)
2727 Break after return type based on ``PenaltyReturnTypeOnItsOwnLine``.
2732 int f() { return 0; };
2735 int f() { return 1; }
2737 LongName::AnotherLongName();
2739 * ``RTBS_ExceptShortType`` (in configuration: ``ExceptShortType``)
2740 Same as ``Automatic`` above, except that there is no break after short
2746 int f() { return 0; };
2749 int f() { return 1; }
2753 * ``RTBS_All`` (in configuration: ``All``)
2754 Always break after the return type.
2771 LongName::AnotherLongName();
2773 * ``RTBS_TopLevel`` (in configuration: ``TopLevel``)
2774 Always break after the return types of top-level functions.
2779 int f() { return 0; };
2788 LongName::AnotherLongName();
2790 * ``RTBS_AllDefinitions`` (in configuration: ``AllDefinitions``)
2791 Always break after the return type of function definitions.
2807 LongName::AnotherLongName();
2809 * ``RTBS_TopLevelDefinitions`` (in configuration: ``TopLevelDefinitions``)
2810 Always break after the return type of top-level definitions.
2815 int f() { return 0; };
2823 LongName::AnotherLongName();
2829 **BreakArrays** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <BreakArrays>`
2830 If ``true``, clang-format will always break after a Json array ``[``
2831 otherwise it will scan until the closing ``]`` to determine if it should
2832 add newlines between elements (prettier compatible).
2837 This is currently only for formatting JSON.
2849 .. _BreakBeforeBinaryOperators:
2851 **BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) :versionbadge:`clang-format 3.6` :ref:`¶ <BreakBeforeBinaryOperators>`
2852 The way to wrap binary operators.
2856 * ``BOS_None`` (in configuration: ``None``)
2857 Break after operators.
2861 LooooooooooongType loooooooooooooooooooooongVariable =
2862 someLooooooooooooooooongFunction();
2864 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
2865 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
2866 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
2867 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
2868 ccccccccccccccccccccccccccccccccccccccccc;
2870 * ``BOS_NonAssignment`` (in configuration: ``NonAssignment``)
2871 Break before operators that aren't assignments.
2875 LooooooooooongType loooooooooooooooooooooongVariable =
2876 someLooooooooooooooooongFunction();
2878 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2879 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2880 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2881 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2882 > ccccccccccccccccccccccccccccccccccccccccc;
2884 * ``BOS_All`` (in configuration: ``All``)
2885 Break before operators.
2889 LooooooooooongType loooooooooooooooooooooongVariable
2890 = someLooooooooooooooooongFunction();
2892 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2893 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2894 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2895 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2896 > ccccccccccccccccccccccccccccccccccccccccc;
2900 .. _BreakBeforeBraces:
2902 **BreakBeforeBraces** (``BraceBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeBraces>`
2903 The brace breaking style to use.
2907 * ``BS_Attach`` (in configuration: ``Attach``)
2908 Always attach braces to surrounding context.
2951 void bar() { foo(true); }
2954 * ``BS_Linux`` (in configuration: ``Linux``)
2955 Like ``Attach``, but break before braces on function, namespace and
3003 void bar() { foo(true); }
3006 * ``BS_Mozilla`` (in configuration: ``Mozilla``)
3007 Like ``Attach``, but break before braces on enum, function, and record
3055 void bar() { foo(true); }
3058 * ``BS_Stroustrup`` (in configuration: ``Stroustrup``)
3059 Like ``Attach``, but break before function definitions, ``catch``, and
3107 void bar() { foo(true); }
3110 * ``BS_Allman`` (in configuration: ``Allman``)
3111 Always break before braces.
3169 void bar() { foo(true); }
3172 * ``BS_Whitesmiths`` (in configuration: ``Whitesmiths``)
3173 Like ``Allman`` but always indent braces and line up code with braces.
3231 void bar() { foo(true); }
3234 * ``BS_GNU`` (in configuration: ``GNU``)
3235 Always break before braces and add an extra level of indentation to
3236 braces of control statements, not to those of class, function
3237 or other definitions.
3296 void bar() { foo(true); }
3299 * ``BS_WebKit`` (in configuration: ``WebKit``)
3300 Like ``Attach``, but break before functions.
3345 void bar() { foo(true); }
3348 * ``BS_Custom`` (in configuration: ``Custom``)
3349 Configure each individual brace in ``BraceWrapping``.
3353 .. _BreakBeforeConceptDeclarations:
3355 **BreakBeforeConceptDeclarations** (``BreakBeforeConceptDeclarationsStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BreakBeforeConceptDeclarations>`
3356 The concept declaration style to use.
3360 * ``BBCDS_Never`` (in configuration: ``Never``)
3361 Keep the template declaration line together with ``concept``.
3365 template <typename T> concept C = ...;
3367 * ``BBCDS_Allowed`` (in configuration: ``Allowed``)
3368 Breaking between template declaration and ``concept`` is allowed. The
3369 actual behavior depends on the content and line breaking rules and
3372 * ``BBCDS_Always`` (in configuration: ``Always``)
3373 Always break before ``concept``, putting it in the line after the
3374 template declaration.
3378 template <typename T>
3383 .. _BreakBeforeInlineASMColon:
3385 **BreakBeforeInlineASMColon** (``BreakBeforeInlineASMColonStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakBeforeInlineASMColon>`
3386 The inline ASM colon style to use.
3390 * ``BBIAS_Never`` (in configuration: ``Never``)
3391 No break before inline ASM colon.
3395 asm volatile("string", : : val);
3397 * ``BBIAS_OnlyMultiline`` (in configuration: ``OnlyMultiline``)
3398 Break before inline ASM colon if the line length is longer than column
3403 asm volatile("string", : : val);
3404 asm("cmoveq %1, %2, %[result]"
3405 : [result] "=r"(result)
3406 : "r"(test), "r"(new), "[result]"(old));
3408 * ``BBIAS_Always`` (in configuration: ``Always``)
3409 Always break before inline ASM colon.
3413 asm volatile("string",
3419 .. _BreakBeforeTernaryOperators:
3421 **BreakBeforeTernaryOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeTernaryOperators>`
3422 If ``true``, ternary operators will be placed after line breaks.
3427 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription
3429 : SecondValueVeryVeryVeryVeryLong;
3432 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription ?
3434 SecondValueVeryVeryVeryVeryLong;
3436 .. _BreakBinaryOperations:
3438 **BreakBinaryOperations** (``BreakBinaryOperationsStyle``) :versionbadge:`clang-format 20` :ref:`¶ <BreakBinaryOperations>`
3439 The break constructor initializers style to use.
3443 * ``BBO_Never`` (in configuration: ``Never``)
3444 Don't break binary operations
3448 aaa + bbbb * ccccc - ddddd +
3451 * ``BBO_OnePerLine`` (in configuration: ``OnePerLine``)
3452 Binary operations will either be all on the same line, or each operation
3453 will have one line each.
3463 * ``BBO_RespectPrecedence`` (in configuration: ``RespectPrecedence``)
3464 Binary operations of a particular precedence that exceed the column
3465 limit will have one line each.
3476 .. _BreakConstructorInitializers:
3478 **BreakConstructorInitializers** (``BreakConstructorInitializersStyle``) :versionbadge:`clang-format 5` :ref:`¶ <BreakConstructorInitializers>`
3479 The break constructor initializers style to use.
3483 * ``BCIS_BeforeColon`` (in configuration: ``BeforeColon``)
3484 Break constructor initializers before the colon and after the commas.
3492 * ``BCIS_BeforeComma`` (in configuration: ``BeforeComma``)
3493 Break constructor initializers before the colon and commas, and align
3494 the commas with the colon.
3502 * ``BCIS_AfterColon`` (in configuration: ``AfterColon``)
3503 Break constructor initializers after the colon and commas.
3513 .. _BreakFunctionDefinitionParameters:
3515 **BreakFunctionDefinitionParameters** (``Boolean``) :versionbadge:`clang-format 19` :ref:`¶ <BreakFunctionDefinitionParameters>`
3516 If ``true``, clang-format will always break before function definition
3522 void functionDefinition(
3526 void functionDefinition(int A, int B) {}
3528 .. _BreakInheritanceList:
3530 **BreakInheritanceList** (``BreakInheritanceListStyle``) :versionbadge:`clang-format 7` :ref:`¶ <BreakInheritanceList>`
3531 The inheritance list style to use.
3535 * ``BILS_BeforeColon`` (in configuration: ``BeforeColon``)
3536 Break inheritance list before the colon and after the commas.
3545 * ``BILS_BeforeComma`` (in configuration: ``BeforeComma``)
3546 Break inheritance list before the colon and commas, and align
3547 the commas with the colon.
3556 * ``BILS_AfterColon`` (in configuration: ``AfterColon``)
3557 Break inheritance list after the colon and commas.
3566 * ``BILS_AfterComma`` (in configuration: ``AfterComma``)
3567 Break inheritance list only after the commas.
3577 .. _BreakStringLiterals:
3579 **BreakStringLiterals** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <BreakStringLiterals>`
3580 Allow breaking string literals when formatting.
3582 In C, C++, and Objective-C:
3587 const char* x = "veryVeryVeryVeryVeryVe"
3588 "ryVeryVeryVeryVeryVery"
3593 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
3600 string x = "veryVeryVeryVeryVeryVe" +
3601 "ryVeryVeryVeryVeryVery" +
3606 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
3608 C# interpolated strings are not broken.
3615 string x = {"veryVeryVeryVeryVeryVe",
3616 "ryVeryVeryVeryVeryVery",
3621 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
3623 .. _BreakTemplateDeclarations:
3625 **BreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``) :versionbadge:`clang-format 19` :ref:`¶ <BreakTemplateDeclarations>`
3626 The template declaration breaking style to use.
3630 * ``BTDS_Leave`` (in configuration: ``Leave``)
3631 Do not change the line breaking before the declaration.
3635 template <typename T>
3638 template <typename T> T foo(int aaaaaaaaaaaaaaaaaaaaa,
3639 int bbbbbbbbbbbbbbbbbbbbb) {
3642 * ``BTDS_No`` (in configuration: ``No``)
3643 Do not force break before declaration.
3644 ``PenaltyBreakTemplateDeclaration`` is taken into account.
3648 template <typename T> T foo() {
3650 template <typename T> T foo(int aaaaaaaaaaaaaaaaaaaaa,
3651 int bbbbbbbbbbbbbbbbbbbbb) {
3654 * ``BTDS_MultiLine`` (in configuration: ``MultiLine``)
3655 Force break after template declaration only when the following
3656 declaration spans multiple lines.
3660 template <typename T> T foo() {
3662 template <typename T>
3663 T foo(int aaaaaaaaaaaaaaaaaaaaa,
3664 int bbbbbbbbbbbbbbbbbbbbb) {
3667 * ``BTDS_Yes`` (in configuration: ``Yes``)
3668 Always break after template declaration.
3672 template <typename T>
3675 template <typename T>
3676 T foo(int aaaaaaaaaaaaaaaaaaaaa,
3677 int bbbbbbbbbbbbbbbbbbbbb) {
3684 **ColumnLimit** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ColumnLimit>`
3687 A column limit of ``0`` means that there is no column limit. In this case,
3688 clang-format will respect the input's line breaking decisions within
3689 statements unless they contradict other rules.
3693 **CommentPragmas** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <CommentPragmas>`
3694 A regular expression that describes comments with special meaning,
3695 which should not be split into lines or otherwise changed.
3699 // CommentPragmas: '^ FOOBAR pragma:'
3700 // Will leave the following line unaffected
3701 #include <vector> // FOOBAR pragma: keep
3703 .. _CompactNamespaces:
3705 **CompactNamespaces** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <CompactNamespaces>`
3706 If ``true``, consecutive namespace declarations will be on the same
3707 line. If ``false``, each namespace is declared on a new line.
3712 namespace Foo { namespace Bar {
3721 If it does not fit on a single line, the overflowing namespaces get
3726 namespace Foo { namespace Bar {
3730 .. _ConstructorInitializerAllOnOneLineOrOnePerLine:
3732 **ConstructorInitializerAllOnOneLineOrOnePerLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerAllOnOneLineOrOnePerLine>`
3733 This option is **deprecated**. See ``CurrentLine`` of
3734 ``PackConstructorInitializers``.
3736 .. _ConstructorInitializerIndentWidth:
3738 **ConstructorInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerIndentWidth>`
3739 The number of characters to use for indentation of constructor
3740 initializer lists as well as inheritance lists.
3742 .. _ContinuationIndentWidth:
3744 **ContinuationIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ContinuationIndentWidth>`
3745 Indent width for line continuations.
3749 ContinuationIndentWidth: 2
3751 int i = // VeryVeryVeryVeryVeryLongComment
3752 longFunction( // Again a long comment
3755 .. _Cpp11BracedListStyle:
3757 **Cpp11BracedListStyle** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <Cpp11BracedListStyle>`
3758 If ``true``, format braced lists as best suited for C++11 braced
3761 Important differences:
3762 - No spaces inside the braced list.
3763 - No line break before the closing brace.
3764 - Indentation with the continuation indent, not with the block indent.
3766 Fundamentally, C++11 braced lists are formatted exactly like function
3767 calls would be formatted in their place. If the braced list follows a name
3768 (e.g. a type or variable name), clang-format formats as if the ``{}`` were
3769 the parentheses of a function call with that name. If there is no name,
3770 a zero-length name is assumed.
3775 vector<int> x{1, 2, 3, 4}; vs. vector<int> x{ 1, 2, 3, 4 };
3776 vector<T> x{{}, {}, {}, {}}; vector<T> x{ {}, {}, {}, {} };
3777 f(MyMap[{composite, key}]); f(MyMap[{ composite, key }]);
3778 new int[3]{1, 2, 3}; new int[3]{ 1, 2, 3 };
3780 .. _DeriveLineEnding:
3782 **DeriveLineEnding** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <DeriveLineEnding>`
3783 This option is **deprecated**. See ``DeriveLF`` and ``DeriveCRLF`` of
3786 .. _DerivePointerAlignment:
3788 **DerivePointerAlignment** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DerivePointerAlignment>`
3789 If ``true``, analyze the formatted file for the most common
3790 alignment of ``&`` and ``*``.
3791 Pointer and reference alignment styles are going to be updated according
3792 to the preferences found in the file.
3793 ``PointerAlignment`` is then used only as fallback.
3797 **DisableFormat** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DisableFormat>`
3798 Disables formatting completely.
3800 .. _EmptyLineAfterAccessModifier:
3802 **EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) :versionbadge:`clang-format 13` :ref:`¶ <EmptyLineAfterAccessModifier>`
3803 Defines when to put an empty line after access modifiers.
3804 ``EmptyLineBeforeAccessModifier`` configuration handles the number of
3805 empty lines between two access modifiers.
3809 * ``ELAAMS_Never`` (in configuration: ``Never``)
3810 Remove all empty lines after access modifiers.
3826 * ``ELAAMS_Leave`` (in configuration: ``Leave``)
3827 Keep existing empty lines after access modifiers.
3828 MaxEmptyLinesToKeep is applied instead.
3830 * ``ELAAMS_Always`` (in configuration: ``Always``)
3831 Always add empty line after access modifiers if there are none.
3832 MaxEmptyLinesToKeep is applied also.
3855 .. _EmptyLineBeforeAccessModifier:
3857 **EmptyLineBeforeAccessModifier** (``EmptyLineBeforeAccessModifierStyle``) :versionbadge:`clang-format 12` :ref:`¶ <EmptyLineBeforeAccessModifier>`
3858 Defines in which cases to put empty line before access modifiers.
3862 * ``ELBAMS_Never`` (in configuration: ``Never``)
3863 Remove all empty lines before access modifiers.
3879 * ``ELBAMS_Leave`` (in configuration: ``Leave``)
3880 Keep existing empty lines before access modifiers.
3882 * ``ELBAMS_LogicalBlock`` (in configuration: ``LogicalBlock``)
3883 Add empty line only when access modifier starts a new logical block.
3884 Logical block is a group of one or more member fields or functions.
3902 * ``ELBAMS_Always`` (in configuration: ``Always``)
3903 Always add empty line before access modifiers unless access modifier
3904 is at the start of struct or class definition.
3926 .. _ExperimentalAutoDetectBinPacking:
3928 **ExperimentalAutoDetectBinPacking** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ExperimentalAutoDetectBinPacking>`
3929 If ``true``, clang-format detects whether function calls and
3930 definitions are formatted with one parameter per line.
3932 Each call can be bin-packed, one-per-line or inconclusive. If it is
3933 inconclusive, e.g. completely on one line, but a decision needs to be
3934 made, clang-format analyzes whether there are other bin-packed cases in
3935 the input file and act accordingly.
3940 This is an experimental flag, that might go away or be renamed. Do
3941 not use this in config files, etc. Use at your own risk.
3943 .. _FixNamespaceComments:
3945 **FixNamespaceComments** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <FixNamespaceComments>`
3946 If ``true``, clang-format adds missing namespace end comments for
3947 namespaces and fixes invalid existing ones. This doesn't affect short
3948 namespaces, which are controlled by ``ShortNamespaceLines``.
3953 namespace longNamespace { vs. namespace longNamespace {
3954 void foo(); void foo();
3955 void bar(); void bar();
3957 namespace shortNamespace { namespace shortNamespace {
3958 void baz(); void baz();
3963 **ForEachMacros** (``List of Strings``) :versionbadge:`clang-format 3.7` :ref:`¶ <ForEachMacros>`
3964 A vector of macros that should be interpreted as foreach loops
3965 instead of as function calls.
3967 These are expected to be macros of the form:
3971 FOREACH(<variable-declaration>, ...)
3974 In the .clang-format configuration file, this can be configured like:
3976 .. code-block:: yaml
3978 ForEachMacros: [RANGES_FOR, FOREACH]
3980 For example: BOOST_FOREACH.
3984 **IfMacros** (``List of Strings``) :versionbadge:`clang-format 13` :ref:`¶ <IfMacros>`
3985 A vector of macros that should be interpreted as conditionals
3986 instead of as function calls.
3988 These are expected to be macros of the form:
3997 In the .clang-format configuration file, this can be configured like:
3999 .. code-block:: yaml
4003 For example: `KJ_IF_MAYBE
4004 <https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes>`_
4008 **IncludeBlocks** (``IncludeBlocksStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IncludeBlocks>`
4009 Dependent on the value, multiple ``#include`` blocks can be sorted
4010 as one and divided based on category.
4014 * ``IBS_Preserve`` (in configuration: ``Preserve``)
4015 Sort each ``#include`` block separately.
4019 #include "b.h" into #include "b.h"
4021 #include <lib/main.h> #include "a.h"
4022 #include "a.h" #include <lib/main.h>
4024 * ``IBS_Merge`` (in configuration: ``Merge``)
4025 Merge multiple ``#include`` blocks together and sort as one.
4029 #include "b.h" into #include "a.h"
4031 #include <lib/main.h> #include <lib/main.h>
4034 * ``IBS_Regroup`` (in configuration: ``Regroup``)
4035 Merge multiple ``#include`` blocks together and sort as one.
4036 Then split into groups based on category priority. See
4037 ``IncludeCategories``.
4041 #include "b.h" into #include "a.h"
4043 #include <lib/main.h>
4044 #include "a.h" #include <lib/main.h>
4048 .. _IncludeCategories:
4050 **IncludeCategories** (``List of IncludeCategories``) :versionbadge:`clang-format 3.8` :ref:`¶ <IncludeCategories>`
4051 Regular expressions denoting the different ``#include`` categories
4052 used for ordering ``#includes``.
4055 <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
4056 regular expressions are supported.
4058 These regular expressions are matched against the filename of an include
4059 (including the <> or "") in order. The value belonging to the first
4060 matching regular expression is assigned and ``#includes`` are sorted first
4061 according to increasing category number and then alphabetically within
4064 If none of the regular expressions match, INT_MAX is assigned as
4065 category. The main header for a source file automatically gets category 0.
4066 so that it is generally kept at the beginning of the ``#includes``
4067 (https://llvm.org/docs/CodingStandards.html#include-style). However, you
4068 can also assign negative priorities if you have certain headers that
4069 always need to be first.
4071 There is a third and optional field ``SortPriority`` which can used while
4072 ``IncludeBlocks = IBS_Regroup`` to define the priority in which
4073 ``#includes`` should be ordered. The value of ``Priority`` defines the
4074 order of ``#include blocks`` and also allows the grouping of ``#includes``
4075 of different priority. ``SortPriority`` is set to the value of
4076 ``Priority`` as default if it is not assigned.
4078 Each regular expression can be marked as case sensitive with the field
4079 ``CaseSensitive``, per default it is not.
4081 To configure this in the .clang-format file, use:
4083 .. code-block:: yaml
4086 - Regex: '^"(llvm|llvm-c|clang|clang-c)/'
4090 - Regex: '^((<|")(gtest|gmock|isl|json)/)'
4092 - Regex: '<[[:alnum:].]+>'
4098 .. _IncludeIsMainRegex:
4100 **IncludeIsMainRegex** (``String``) :versionbadge:`clang-format 3.9` :ref:`¶ <IncludeIsMainRegex>`
4101 Specify a regular expression of suffixes that are allowed in the
4102 file-to-main-include mapping.
4104 When guessing whether a #include is the "main" include (to assign
4105 category 0, see above), use this regex of allowed suffixes to the header
4106 stem. A partial match is done, so that:
4107 - "" means "arbitrary suffix"
4108 - "$" means "no suffix"
4110 For example, if configured to "(_test)?$", then a header a.h would be seen
4111 as the "main" include in both a.cc and a_test.cc.
4113 .. _IncludeIsMainSourceRegex:
4115 **IncludeIsMainSourceRegex** (``String``) :versionbadge:`clang-format 10` :ref:`¶ <IncludeIsMainSourceRegex>`
4116 Specify a regular expression for files being formatted
4117 that are allowed to be considered "main" in the
4118 file-to-main-include mapping.
4120 By default, clang-format considers files as "main" only when they end
4121 with: ``.c``, ``.cc``, ``.cpp``, ``.c++``, ``.cxx``, ``.m`` or ``.mm``
4123 For these files a guessing of "main" include takes place
4124 (to assign category 0, see above). This config option allows for
4125 additional suffixes and extensions for files to be considered as "main".
4127 For example, if this option is configured to ``(Impl\.hpp)$``,
4128 then a file ``ClassImpl.hpp`` is considered "main" (in addition to
4129 ``Class.c``, ``Class.cc``, ``Class.cpp`` and so on) and "main
4130 include file" logic will be executed (with *IncludeIsMainRegex* setting
4131 also being respected in later phase). Without this option set,
4132 ``ClassImpl.hpp`` would not have the main include file put on top
4133 before any other include.
4135 .. _IndentAccessModifiers:
4137 **IndentAccessModifiers** (``Boolean``) :versionbadge:`clang-format 13` :ref:`¶ <IndentAccessModifiers>`
4138 Specify whether access modifiers should have their own indentation level.
4140 When ``false``, access modifiers are indented (or outdented) relative to
4141 the record members, respecting the ``AccessModifierOffset``. Record
4142 members are indented one level below the record.
4143 When ``true``, access modifiers get their own indentation level. As a
4144 consequence, record members are always indented 2 levels below the record,
4145 regardless of the access modifier presence. Value of the
4146 ``AccessModifierOffset`` is ignored.
4151 class C { vs. class C {
4153 void bar(); void bar();
4154 protected: protected:
4160 void foo() { void foo() {
4164 .. _IndentCaseBlocks:
4166 **IndentCaseBlocks** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <IndentCaseBlocks>`
4167 Indent case label blocks one level from the case label.
4169 When ``false``, the block following the case label uses the same
4170 indentation level as for the case label, treating the case label the same
4172 When ``true``, the block gets indented as a scope block.
4177 switch (fool) { vs. switch (fool) {
4189 .. _IndentCaseLabels:
4191 **IndentCaseLabels** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <IndentCaseLabels>`
4192 Indent case labels one level from the switch statement.
4194 When ``false``, use the same indentation level as for the switch
4195 statement. Switch statement body is always indented one level more than
4196 case labels (except the first block following the case label, which
4197 itself indents the code - unless IndentCaseBlocks is enabled).
4202 switch (fool) { vs. switch (fool) {
4210 .. _IndentExternBlock:
4212 **IndentExternBlock** (``IndentExternBlockStyle``) :versionbadge:`clang-format 11` :ref:`¶ <IndentExternBlock>`
4213 IndentExternBlockStyle is the type of indenting of extern blocks.
4217 * ``IEBS_AfterExternBlock`` (in configuration: ``AfterExternBlock``)
4218 Backwards compatible with AfterExternBlock's indenting.
4222 IndentExternBlock: AfterExternBlock
4223 BraceWrapping.AfterExternBlock: true
4232 IndentExternBlock: AfterExternBlock
4233 BraceWrapping.AfterExternBlock: false
4238 * ``IEBS_NoIndent`` (in configuration: ``NoIndent``)
4239 Does not indent extern blocks.
4247 * ``IEBS_Indent`` (in configuration: ``Indent``)
4248 Indents extern blocks.
4258 .. _IndentGotoLabels:
4260 **IndentGotoLabels** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <IndentGotoLabels>`
4263 When ``false``, goto labels are flushed left.
4268 int f() { vs. int f() {
4269 if (foo()) { if (foo()) {
4277 .. _IndentPPDirectives:
4279 **IndentPPDirectives** (``PPDirectiveIndentStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IndentPPDirectives>`
4280 The preprocessor directive indenting style to use.
4284 * ``PPDIS_None`` (in configuration: ``None``)
4285 Does not indent any directives.
4295 * ``PPDIS_AfterHash`` (in configuration: ``AfterHash``)
4296 Indents directives after the hash.
4306 * ``PPDIS_BeforeHash`` (in configuration: ``BeforeHash``)
4307 Indents directives before the hash.
4319 .. _IndentRequiresClause:
4321 **IndentRequiresClause** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <IndentRequiresClause>`
4322 Indent the requires clause in a template. This only applies when
4323 ``RequiresClausePosition`` is ``OwnLine``, ``OwnLineWithBrace``,
4324 or ``WithFollowing``.
4326 In clang-format 12, 13 and 14 it was named ``IndentRequires``.
4331 template <typename It>
4332 requires Iterator<It>
4333 void sort(It begin, It end) {
4338 template <typename It>
4339 requires Iterator<It>
4340 void sort(It begin, It end) {
4346 **IndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWidth>`
4347 The number of columns to use for indentation.
4360 .. _IndentWrappedFunctionNames:
4362 **IndentWrappedFunctionNames** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWrappedFunctionNames>`
4363 Indent if a function definition or declaration is wrapped after the
4369 LoooooooooooooooooooooooooooooooooooooooongReturnType
4370 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
4373 LoooooooooooooooooooooooooooooooooooooooongReturnType
4374 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
4378 **InsertBraces** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <InsertBraces>`
4379 Insert braces after control statements (``if``, ``else``, ``for``, ``do``,
4380 and ``while``) in C++ unless the control statements are inside macro
4381 definitions or the braces would enclose preprocessor directives.
4385 Setting this option to ``true`` could lead to incorrect code formatting
4386 due to clang-format's lack of complete semantic information. As such,
4387 extra care should be taken to review code changes made by this option.
4393 if (isa<FunctionDecl>(D)) vs. if (isa<FunctionDecl>(D)) {
4394 handleFunctionDecl(D); handleFunctionDecl(D);
4395 else if (isa<VarDecl>(D)) } else if (isa<VarDecl>(D)) {
4396 handleVarDecl(D); handleVarDecl(D);
4401 while (i--) vs. while (i--) {
4402 for (auto *A : D.attrs()) for (auto *A : D.attrs()) {
4403 handleAttr(A); handleAttr(A);
4409 while (i); } while (i);
4411 .. _InsertNewlineAtEOF:
4413 **InsertNewlineAtEOF** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <InsertNewlineAtEOF>`
4414 Insert a newline at end of file if missing.
4416 .. _InsertTrailingCommas:
4418 **InsertTrailingCommas** (``TrailingCommaStyle``) :versionbadge:`clang-format 11` :ref:`¶ <InsertTrailingCommas>`
4419 If set to ``TCS_Wrapped`` will insert trailing commas in container
4420 literals (arrays and objects) that wrap across multiple lines.
4421 It is currently only available for JavaScript
4422 and disabled by default ``TCS_None``.
4423 ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
4424 as inserting the comma disables bin-packing.
4430 aaaaaaaaaaaaaaaaaaaaaaaaaa,
4431 aaaaaaaaaaaaaaaaaaaaaaaaaa,
4432 aaaaaaaaaaaaaaaaaaaaaaaaaa,
4438 * ``TCS_None`` (in configuration: ``None``)
4439 Do not insert trailing commas.
4441 * ``TCS_Wrapped`` (in configuration: ``Wrapped``)
4442 Insert trailing commas in container literals that were wrapped over
4443 multiple lines. Note that this is conceptually incompatible with
4444 bin-packing, because the trailing comma is used as an indicator
4445 that a container should be formatted one-per-line (i.e. not bin-packed).
4446 So inserting a trailing comma counteracts bin-packing.
4450 .. _IntegerLiteralSeparator:
4452 **IntegerLiteralSeparator** (``IntegerLiteralSeparatorStyle``) :versionbadge:`clang-format 16` :ref:`¶ <IntegerLiteralSeparator>`
4453 Format integer literal separators (``'`` for C++ and ``_`` for C#, Java,
4456 Nested configuration flags:
4458 Separator format of integer literals of different bases.
4460 If negative, remove separators. If ``0``, leave the literal as is. If
4461 positive, insert separators between digits starting from the rightmost
4464 For example, the config below will leave separators in binary literals
4465 alone, insert separators in decimal literals to separate the digits into
4466 groups of 3, and remove separators in hexadecimal literals.
4470 IntegerLiteralSeparator:
4475 You can also specify a minimum number of digits (``BinaryMinDigits``,
4476 ``DecimalMinDigits``, and ``HexMinDigits``) the integer literal must
4477 have in order for the separators to be inserted.
4479 * ``int8_t Binary`` Format separators in binary literals.
4481 .. code-block:: text
4483 /* -1: */ b = 0b100111101101;
4484 /* 0: */ b = 0b10011'11'0110'1;
4485 /* 3: */ b = 0b100'111'101'101;
4486 /* 4: */ b = 0b1001'1110'1101;
4488 * ``int8_t BinaryMinDigits`` Format separators in binary literals with a minimum number of digits.
4490 .. code-block:: text
4493 // BinaryMinDigits: 7
4497 * ``int8_t Decimal`` Format separators in decimal literals.
4499 .. code-block:: text
4501 /* -1: */ d = 18446744073709550592ull;
4502 /* 0: */ d = 184467'440737'0'95505'92ull;
4503 /* 3: */ d = 18'446'744'073'709'550'592ull;
4505 * ``int8_t DecimalMinDigits`` Format separators in decimal literals with a minimum number of digits.
4507 .. code-block:: text
4510 // DecimalMinDigits: 5
4514 * ``int8_t Hex`` Format separators in hexadecimal literals.
4516 .. code-block:: text
4518 /* -1: */ h = 0xDEADBEEFDEADBEEFuz;
4519 /* 0: */ h = 0xDEAD'BEEF'DE'AD'BEE'Fuz;
4520 /* 2: */ h = 0xDE'AD'BE'EF'DE'AD'BE'EFuz;
4522 * ``int8_t HexMinDigits`` Format separators in hexadecimal literals with a minimum number of
4525 .. code-block:: text
4533 .. _JavaImportGroups:
4535 **JavaImportGroups** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <JavaImportGroups>`
4536 A vector of prefixes ordered by the desired groups for Java imports.
4538 One group's prefix can be a subset of another - the longest prefix is
4539 always matched. Within a group, the imports are ordered lexicographically.
4540 Static imports are grouped separately and follow the same group rules.
4541 By default, static imports are placed before non-static imports,
4542 but this behavior is changed by another option,
4543 ``SortJavaStaticImport``.
4545 In the .clang-format configuration file, this can be configured like
4546 in the following yaml example. This will result in imports being
4547 formatted as in the Java example below.
4549 .. code-block:: yaml
4551 JavaImportGroups: [com.example, com, org]
4554 .. code-block:: java
4556 import static com.example.function1;
4558 import static com.test.function2;
4560 import static org.example.function3;
4562 import com.example.ClassA;
4563 import com.example.Test;
4564 import com.example.a.ClassB;
4566 import com.test.ClassC;
4568 import org.example.ClassD;
4570 .. _JavaScriptQuotes:
4572 **JavaScriptQuotes** (``JavaScriptQuoteStyle``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptQuotes>`
4573 The JavaScriptQuoteStyle to use for JavaScript strings.
4577 * ``JSQS_Leave`` (in configuration: ``Leave``)
4578 Leave string quotes as they are.
4585 * ``JSQS_Single`` (in configuration: ``Single``)
4586 Always use single quotes.
4593 * ``JSQS_Double`` (in configuration: ``Double``)
4594 Always use double quotes.
4603 .. _JavaScriptWrapImports:
4605 **JavaScriptWrapImports** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptWrapImports>`
4606 Whether to wrap JavaScript import/export statements.
4612 VeryLongImportsAreAnnoying,
4613 VeryLongImportsAreAnnoying,
4614 VeryLongImportsAreAnnoying,
4615 } from "some/module.js"
4618 import {VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying,} from "some/module.js"
4622 **KeepEmptyLines** (``KeepEmptyLinesStyle``) :versionbadge:`clang-format 19` :ref:`¶ <KeepEmptyLines>`
4623 Which empty lines are kept. See ``MaxEmptyLinesToKeep`` for how many
4624 consecutive empty lines are kept.
4626 Nested configuration flags:
4628 Options regarding which empty lines are kept.
4630 For example, the config below will remove empty lines at start of the
4631 file, end of the file, and start of blocks.
4638 AtStartOfBlock: false
4639 AtStartOfFile: false
4641 * ``bool AtEndOfFile`` Keep empty lines at end of file.
4643 * ``bool AtStartOfBlock`` Keep empty lines at start of a block.
4648 if (foo) { vs. if (foo) {
4653 * ``bool AtStartOfFile`` Keep empty lines at start of file.
4656 .. _KeepEmptyLinesAtEOF:
4658 **KeepEmptyLinesAtEOF** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <KeepEmptyLinesAtEOF>`
4659 This option is deprecated. See ``AtEndOfFile`` of ``KeepEmptyLines``.
4661 .. _KeepEmptyLinesAtTheStartOfBlocks:
4663 **KeepEmptyLinesAtTheStartOfBlocks** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <KeepEmptyLinesAtTheStartOfBlocks>`
4664 This option is deprecated. See ``AtStartOfBlock`` of ``KeepEmptyLines``.
4668 **KeepFormFeed** (``Boolean``) :versionbadge:`clang-format 20` :ref:`¶ <KeepFormFeed>`
4669 Keep the form feed character if it's immediately preceded and followed by
4670 a newline. Multiple form feeds and newlines within a whitespace range are
4671 replaced with a single newline and form feed followed by the remaining
4674 .. _LambdaBodyIndentation:
4676 **LambdaBodyIndentation** (``LambdaBodyIndentationKind``) :versionbadge:`clang-format 13` :ref:`¶ <LambdaBodyIndentation>`
4677 The indentation style of lambda bodies. ``Signature`` (the default)
4678 causes the lambda body to be indented one additional level relative to
4679 the indentation level of the signature. ``OuterScope`` forces the lambda
4680 body to be indented one additional level relative to the parent scope
4681 containing the lambda signature.
4685 * ``LBI_Signature`` (in configuration: ``Signature``)
4686 Align lambda body relative to the lambda signature. This is the default.
4691 [](SomeReallyLongLambdaSignatureArgument foo) {
4695 * ``LBI_OuterScope`` (in configuration: ``OuterScope``)
4696 For statements within block scope, align lambda body relative to the
4697 indentation level of the outer scope the lambda signature resides in.
4702 [](SomeReallyLongLambdaSignatureArgument foo) {
4706 someMethod(someOtherMethod(
4707 [](SomeReallyLongLambdaSignatureArgument foo) {
4715 **Language** (``LanguageKind``) :versionbadge:`clang-format 3.5` :ref:`¶ <Language>`
4716 Language, this format style is targeted at.
4720 * ``LK_None`` (in configuration: ``None``)
4723 * ``LK_Cpp`` (in configuration: ``Cpp``)
4724 Should be used for C, C++.
4726 * ``LK_CSharp`` (in configuration: ``CSharp``)
4727 Should be used for C#.
4729 * ``LK_Java`` (in configuration: ``Java``)
4730 Should be used for Java.
4732 * ``LK_JavaScript`` (in configuration: ``JavaScript``)
4733 Should be used for JavaScript.
4735 * ``LK_Json`` (in configuration: ``Json``)
4736 Should be used for JSON.
4738 * ``LK_ObjC`` (in configuration: ``ObjC``)
4739 Should be used for Objective-C, Objective-C++.
4741 * ``LK_Proto`` (in configuration: ``Proto``)
4742 Should be used for Protocol Buffers
4743 (https://developers.google.com/protocol-buffers/).
4745 * ``LK_TableGen`` (in configuration: ``TableGen``)
4746 Should be used for TableGen code.
4748 * ``LK_TextProto`` (in configuration: ``TextProto``)
4749 Should be used for Protocol Buffer messages in text format
4750 (https://developers.google.com/protocol-buffers/).
4752 * ``LK_Verilog`` (in configuration: ``Verilog``)
4753 Should be used for Verilog and SystemVerilog.
4754 https://standards.ieee.org/ieee/1800/6700/
4755 https://sci-hub.st/10.1109/IEEESTD.2018.8299595
4761 **LineEnding** (``LineEndingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <LineEnding>`
4762 Line ending style (``\n`` or ``\r\n``) to use.
4766 * ``LE_LF`` (in configuration: ``LF``)
4769 * ``LE_CRLF`` (in configuration: ``CRLF``)
4772 * ``LE_DeriveLF`` (in configuration: ``DeriveLF``)
4773 Use ``\n`` unless the input has more lines ending in ``\r\n``.
4775 * ``LE_DeriveCRLF`` (in configuration: ``DeriveCRLF``)
4776 Use ``\r\n`` unless the input has more lines ending in ``\n``.
4780 .. _MacroBlockBegin:
4782 **MacroBlockBegin** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockBegin>`
4783 A regular expression matching macros that start a block.
4788 MacroBlockBegin: "^NS_MAP_BEGIN|\
4813 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockEnd>`
4814 A regular expression matching macros that end a block.
4818 **Macros** (``List of Strings``) :versionbadge:`clang-format 17` :ref:`¶ <Macros>`
4819 A list of macros of the form ``<definition>=<expansion>`` .
4821 Code will be parsed with macros expanded, in order to determine how to
4822 interpret and format the macro arguments.
4824 For example, the code:
4830 will usually be interpreted as a call to a function A, and the
4831 multiplication expression will be formatted as ``a * b``.
4833 If we specify the macro definition:
4835 .. code-block:: yaml
4840 the code will now be parsed as a declaration of the variable b of type a*,
4841 and formatted as ``a* b`` (depending on pointer-binding rules).
4843 Features and restrictions:
4844 * Both function-like macros and object-like macros are supported.
4845 * Macro arguments must be used exactly once in the expansion.
4846 * No recursive expansion; macros referencing other macros will be
4848 * Overloading by arity is supported: for example, given the macro
4849 definitions A=x, A()=y, A(a)=a
4857 A(a, b); // will not be expanded.
4859 .. _MainIncludeChar:
4861 **MainIncludeChar** (``MainIncludeCharDiscriminator``) :versionbadge:`clang-format 19` :ref:`¶ <MainIncludeChar>`
4862 When guessing whether a #include is the "main" include, only the include
4863 directives that use the specified character are considered.
4867 * ``MICD_Quote`` (in configuration: ``Quote``)
4868 Main include uses quotes: ``#include "foo.hpp"`` (the default).
4870 * ``MICD_AngleBracket`` (in configuration: ``AngleBracket``)
4871 Main include uses angle brackets: ``#include <foo.hpp>``.
4873 * ``MICD_Any`` (in configuration: ``Any``)
4874 Main include uses either quotes or angle brackets.
4878 .. _MaxEmptyLinesToKeep:
4880 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <MaxEmptyLinesToKeep>`
4881 The maximum number of consecutive empty lines to keep.
4885 MaxEmptyLinesToKeep: 1 vs. MaxEmptyLinesToKeep: 0
4889 i = foo(); return i;
4894 .. _NamespaceIndentation:
4896 **NamespaceIndentation** (``NamespaceIndentationKind``) :versionbadge:`clang-format 3.7` :ref:`¶ <NamespaceIndentation>`
4897 The indentation used for namespaces.
4901 * ``NI_None`` (in configuration: ``None``)
4902 Don't indent in namespaces.
4913 * ``NI_Inner`` (in configuration: ``Inner``)
4914 Indent only in inner namespaces (nested in other namespaces).
4925 * ``NI_All`` (in configuration: ``All``)
4926 Indent in all namespaces.
4939 .. _NamespaceMacros:
4941 **NamespaceMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <NamespaceMacros>`
4942 A vector of macros which are used to open namespace blocks.
4944 These are expected to be macros of the form:
4948 NAMESPACE(<namespace-name>, ...) {
4952 For example: TESTSUITE
4954 .. _ObjCBinPackProtocolList:
4956 **ObjCBinPackProtocolList** (``BinPackStyle``) :versionbadge:`clang-format 7` :ref:`¶ <ObjCBinPackProtocolList>`
4957 Controls bin-packing Objective-C protocol conformance list
4958 items into as few lines as possible when they go over ``ColumnLimit``.
4960 If ``Auto`` (the default), delegates to the value in
4961 ``BinPackParameters``. If that is ``BinPack``, bin-packs Objective-C
4962 protocol conformance list items into as few lines as possible
4963 whenever they go over ``ColumnLimit``.
4965 If ``Always``, always bin-packs Objective-C protocol conformance
4966 list items into as few lines as possible whenever they go over
4969 If ``Never``, lays out Objective-C protocol conformance list items
4970 onto individual lines whenever they go over ``ColumnLimit``.
4973 .. code-block:: objc
4975 Always (or Auto, if BinPackParameters==BinPack):
4976 @interface ccccccccccccc () <
4977 ccccccccccccc, ccccccccccccc,
4978 ccccccccccccc, ccccccccccccc> {
4981 Never (or Auto, if BinPackParameters!=BinPack):
4982 @interface ddddddddddddd () <
4991 * ``BPS_Auto`` (in configuration: ``Auto``)
4992 Automatically determine parameter bin-packing behavior.
4994 * ``BPS_Always`` (in configuration: ``Always``)
4995 Always bin-pack parameters.
4997 * ``BPS_Never`` (in configuration: ``Never``)
4998 Never bin-pack parameters.
5002 .. _ObjCBlockIndentWidth:
5004 **ObjCBlockIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCBlockIndentWidth>`
5005 The number of characters to use for indentation of ObjC blocks.
5007 .. code-block:: objc
5009 ObjCBlockIndentWidth: 4
5011 [operation setCompletionBlock:^{
5012 [self onOperationDone];
5015 .. _ObjCBreakBeforeNestedBlockParam:
5017 **ObjCBreakBeforeNestedBlockParam** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <ObjCBreakBeforeNestedBlockParam>`
5018 Break parameters list into lines when there is nested block
5019 parameters in a function call.
5026 [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
5036 callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
5041 .. _ObjCPropertyAttributeOrder:
5043 **ObjCPropertyAttributeOrder** (``List of Strings``) :versionbadge:`clang-format 18` :ref:`¶ <ObjCPropertyAttributeOrder>`
5044 The order in which ObjC property attributes should appear.
5046 Attributes in code will be sorted in the order specified. Any attributes
5047 encountered that are not mentioned in this array will be sorted last, in
5048 stable order. Comments between attributes will leave the attributes
5053 Using this option could lead to incorrect code formatting due to
5054 clang-format's lack of complete semantic information. As such, extra
5055 care should be taken to review code changes made by this option.
5057 .. code-block:: yaml
5059 ObjCPropertyAttributeOrder: [
5062 assign, retain, strong, copy, weak, unsafe_unretained,
5063 readonly, readwrite, getter, setter,
5064 nullable, nonnull, null_resettable, null_unspecified
5067 .. _ObjCSpaceAfterProperty:
5069 **ObjCSpaceAfterProperty** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceAfterProperty>`
5070 Add a space after ``@property`` in Objective-C, i.e. use
5071 ``@property (readonly)`` instead of ``@property(readonly)``.
5073 .. _ObjCSpaceBeforeProtocolList:
5075 **ObjCSpaceBeforeProtocolList** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceBeforeProtocolList>`
5076 Add a space in front of an Objective-C protocol list, i.e. use
5077 ``Foo <Protocol>`` instead of ``Foo<Protocol>``.
5081 **PPIndentWidth** (``Integer``) :versionbadge:`clang-format 13` :ref:`¶ <PPIndentWidth>`
5082 The number of columns to use for indentation of preprocessor statements.
5083 When set to -1 (default) ``IndentWidth`` is used also for preprocessor
5096 .. _PackConstructorInitializers:
5098 **PackConstructorInitializers** (``PackConstructorInitializersStyle``) :versionbadge:`clang-format 14` :ref:`¶ <PackConstructorInitializers>`
5099 The pack constructor initializers style to use.
5103 * ``PCIS_Never`` (in configuration: ``Never``)
5104 Always put each constructor initializer on its own line.
5112 * ``PCIS_BinPack`` (in configuration: ``BinPack``)
5113 Bin-pack constructor initializers.
5118 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(),
5119 cccccccccccccccccccc()
5121 * ``PCIS_CurrentLine`` (in configuration: ``CurrentLine``)
5122 Put all constructor initializers on the current line if they fit.
5123 Otherwise, put each one on its own line.
5127 Constructor() : a(), b()
5130 : aaaaaaaaaaaaaaaaaaaa(),
5131 bbbbbbbbbbbbbbbbbbbb(),
5134 * ``PCIS_NextLine`` (in configuration: ``NextLine``)
5135 Same as ``PCIS_CurrentLine`` except that if all constructor initializers
5136 do not fit on the current line, try to fit them on the next line.
5140 Constructor() : a(), b()
5143 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), ddddddddddddd()
5146 : aaaaaaaaaaaaaaaaaaaa(),
5147 bbbbbbbbbbbbbbbbbbbb(),
5148 cccccccccccccccccccc()
5150 * ``PCIS_NextLineOnly`` (in configuration: ``NextLineOnly``)
5151 Put all constructor initializers on the next line if they fit.
5152 Otherwise, put each one on its own line.
5160 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), ddddddddddddd()
5163 : aaaaaaaaaaaaaaaaaaaa(),
5164 bbbbbbbbbbbbbbbbbbbb(),
5165 cccccccccccccccccccc()
5169 .. _PenaltyBreakAssignment:
5171 **PenaltyBreakAssignment** (``Unsigned``) :versionbadge:`clang-format 5` :ref:`¶ <PenaltyBreakAssignment>`
5172 The penalty for breaking around an assignment operator.
5174 .. _PenaltyBreakBeforeFirstCallParameter:
5176 **PenaltyBreakBeforeFirstCallParameter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakBeforeFirstCallParameter>`
5177 The penalty for breaking a function call after ``call(``.
5179 .. _PenaltyBreakComment:
5181 **PenaltyBreakComment** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakComment>`
5182 The penalty for each line break introduced inside a comment.
5184 .. _PenaltyBreakFirstLessLess:
5186 **PenaltyBreakFirstLessLess** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakFirstLessLess>`
5187 The penalty for breaking before the first ``<<``.
5189 .. _PenaltyBreakOpenParenthesis:
5191 **PenaltyBreakOpenParenthesis** (``Unsigned``) :versionbadge:`clang-format 14` :ref:`¶ <PenaltyBreakOpenParenthesis>`
5192 The penalty for breaking after ``(``.
5194 .. _PenaltyBreakScopeResolution:
5196 **PenaltyBreakScopeResolution** (``Unsigned``) :versionbadge:`clang-format 18` :ref:`¶ <PenaltyBreakScopeResolution>`
5197 The penalty for breaking after ``::``.
5199 .. _PenaltyBreakString:
5201 **PenaltyBreakString** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakString>`
5202 The penalty for each line break introduced inside a string literal.
5204 .. _PenaltyBreakTemplateDeclaration:
5206 **PenaltyBreakTemplateDeclaration** (``Unsigned``) :versionbadge:`clang-format 7` :ref:`¶ <PenaltyBreakTemplateDeclaration>`
5207 The penalty for breaking after template declaration.
5209 .. _PenaltyExcessCharacter:
5211 **PenaltyExcessCharacter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyExcessCharacter>`
5212 The penalty for each character outside of the column limit.
5214 .. _PenaltyIndentedWhitespace:
5216 **PenaltyIndentedWhitespace** (``Unsigned``) :versionbadge:`clang-format 12` :ref:`¶ <PenaltyIndentedWhitespace>`
5217 Penalty for each character of whitespace indentation
5218 (counted relative to leading non-whitespace column).
5220 .. _PenaltyReturnTypeOnItsOwnLine:
5222 **PenaltyReturnTypeOnItsOwnLine** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyReturnTypeOnItsOwnLine>`
5223 Penalty for putting the return type of a function onto its own line.
5225 .. _PointerAlignment:
5227 **PointerAlignment** (``PointerAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <PointerAlignment>`
5228 Pointer and reference alignment style.
5232 * ``PAS_Left`` (in configuration: ``Left``)
5233 Align pointer to the left.
5239 * ``PAS_Right`` (in configuration: ``Right``)
5240 Align pointer to the right.
5246 * ``PAS_Middle`` (in configuration: ``Middle``)
5247 Align pointer in the middle.
5255 .. _QualifierAlignment:
5257 **QualifierAlignment** (``QualifierAlignmentStyle``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierAlignment>`
5258 Different ways to arrange specifiers and qualifiers (e.g. const/volatile).
5262 Setting ``QualifierAlignment`` to something other than ``Leave``, COULD
5263 lead to incorrect code formatting due to incorrect decisions made due to
5264 clang-formats lack of complete semantic information.
5265 As such extra care should be taken to review code changes made by the use
5270 * ``QAS_Leave`` (in configuration: ``Leave``)
5271 Don't change specifiers/qualifiers to either Left or Right alignment
5279 * ``QAS_Left`` (in configuration: ``Left``)
5280 Change specifiers/qualifiers to be left-aligned.
5287 * ``QAS_Right`` (in configuration: ``Right``)
5288 Change specifiers/qualifiers to be right-aligned.
5295 * ``QAS_Custom`` (in configuration: ``Custom``)
5296 Change specifiers/qualifiers to be aligned based on ``QualifierOrder``.
5299 .. code-block:: yaml
5301 QualifierOrder: [inline, static, type, const]
5314 **QualifierOrder** (``List of Strings``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierOrder>`
5315 The order in which the qualifiers appear.
5316 Order is an array that can contain any of the following:
5330 It **must** contain ``type``.
5332 Items to the left of ``type`` will be placed to the left of the type and
5333 aligned in the order supplied. Items to the right of ``type`` will be
5334 placed to the right of the type and aligned in the order supplied.
5337 .. code-block:: yaml
5339 QualifierOrder: [inline, static, type, const, volatile]
5341 .. _RawStringFormats:
5343 **RawStringFormats** (``List of RawStringFormats``) :versionbadge:`clang-format 6` :ref:`¶ <RawStringFormats>`
5344 Defines hints for detecting supported languages code blocks in raw
5347 A raw string with a matching delimiter or a matching enclosing function
5348 name will be reformatted assuming the specified language based on the
5349 style for that language defined in the .clang-format file. If no style has
5350 been defined in the .clang-format file for the specific language, a
5351 predefined style given by ``BasedOnStyle`` is used. If ``BasedOnStyle`` is
5352 not found, the formatting is based on ``LLVM`` style. A matching delimiter
5353 takes precedence over a matching enclosing function name for determining
5354 the language of the raw string contents.
5356 If a canonical delimiter is specified, occurrences of other delimiters for
5357 the same language will be updated to the canonical if possible.
5359 There should be at most one specification per language and each delimiter
5360 and enclosing function should not occur in multiple specifications.
5362 To configure this in the .clang-format file, use:
5364 .. code-block:: yaml
5367 - Language: TextProto
5373 BasedOnStyle: google
5379 CanonicalDelimiter: cc
5381 .. _ReferenceAlignment:
5383 **ReferenceAlignment** (``ReferenceAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ <ReferenceAlignment>`
5384 Reference alignment style (overrides ``PointerAlignment`` for
5389 * ``RAS_Pointer`` (in configuration: ``Pointer``)
5390 Align reference like ``PointerAlignment``.
5392 * ``RAS_Left`` (in configuration: ``Left``)
5393 Align reference to the left.
5399 * ``RAS_Right`` (in configuration: ``Right``)
5400 Align reference to the right.
5406 * ``RAS_Middle`` (in configuration: ``Middle``)
5407 Align reference in the middle.
5417 **ReflowComments** (``ReflowCommentsStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <ReflowComments>`
5418 Comment reformatting style.
5422 * ``RCS_Never`` (in configuration: ``Never``)
5423 Leave comments untouched.
5427 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
5428 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information */
5429 /* third veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
5430 * and a misaligned second line */
5432 * ``RCS_IndentOnly`` (in configuration: ``IndentOnly``)
5433 Only apply indentation rules, moving comments left or right, without
5434 changing formatting inside the comments.
5438 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
5439 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information */
5440 /* third veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
5441 * and a misaligned second line */
5443 * ``RCS_Always`` (in configuration: ``Always``)
5444 Apply indentation rules and reflow long comments into new lines, trying
5445 to obey the ``ColumnLimit``.
5449 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
5451 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
5453 /* third veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
5454 * information and a misaligned second line */
5458 .. _RemoveBracesLLVM:
5460 **RemoveBracesLLVM** (``Boolean``) :versionbadge:`clang-format 14` :ref:`¶ <RemoveBracesLLVM>`
5461 Remove optional braces of control statements (``if``, ``else``, ``for``,
5462 and ``while``) in C++ according to the LLVM coding style.
5466 This option will be renamed and expanded to support other styles.
5470 Setting this option to ``true`` could lead to incorrect code formatting
5471 due to clang-format's lack of complete semantic information. As such,
5472 extra care should be taken to review code changes made by this option.
5478 if (isa<FunctionDecl>(D)) { vs. if (isa<FunctionDecl>(D))
5479 handleFunctionDecl(D); handleFunctionDecl(D);
5480 } else if (isa<VarDecl>(D)) { else if (isa<VarDecl>(D))
5481 handleVarDecl(D); handleVarDecl(D);
5484 if (isa<VarDecl>(D)) { vs. if (isa<VarDecl>(D)) {
5485 for (auto *A : D.attrs()) { for (auto *A : D.attrs())
5486 if (shouldProcessAttr(A)) { if (shouldProcessAttr(A))
5487 handleAttr(A); handleAttr(A);
5492 if (isa<FunctionDecl>(D)) { vs. if (isa<FunctionDecl>(D))
5493 for (auto *A : D.attrs()) { for (auto *A : D.attrs())
5494 handleAttr(A); handleAttr(A);
5498 if (auto *D = (T)(D)) { vs. if (auto *D = (T)(D)) {
5499 if (shouldProcess(D)) { if (shouldProcess(D))
5500 handleVarDecl(D); handleVarDecl(D);
5502 markAsIgnored(D); markAsIgnored(D);
5508 } else { else if (c)
5516 .. _RemoveEmptyLinesInUnwrappedLines:
5518 **RemoveEmptyLinesInUnwrappedLines** (``Boolean``) :versionbadge:`clang-format 20` :ref:`¶ <RemoveEmptyLinesInUnwrappedLines>`
5519 Remove empty lines within unwrapped lines.
5525 int c vs. int c = a + b;
5529 enum : unsigned vs. enum : unsigned {
5536 while ( vs. while (true) {
5541 .. _RemoveParentheses:
5543 **RemoveParentheses** (``RemoveParenthesesStyle``) :versionbadge:`clang-format 17` :ref:`¶ <RemoveParentheses>`
5544 Remove redundant parentheses.
5548 Setting this option to any value other than ``Leave`` could lead to
5549 incorrect code formatting due to clang-format's lack of complete semantic
5550 information. As such, extra care should be taken to review code changes
5551 made by this option.
5555 * ``RPS_Leave`` (in configuration: ``Leave``)
5556 Do not remove parentheses.
5560 class __declspec((dllimport)) X {};
5562 return ((a + b) - ((c + d)));
5564 * ``RPS_MultipleParentheses`` (in configuration: ``MultipleParentheses``)
5565 Replace multiple parentheses with single parentheses.
5569 class __declspec(dllimport) X {};
5571 return ((a + b) - (c + d));
5573 * ``RPS_ReturnStatement`` (in configuration: ``ReturnStatement``)
5574 Also remove parentheses enclosing the expression in a
5575 ``return``/``co_return`` statement.
5579 class __declspec(dllimport) X {};
5581 return (a + b) - (c + d);
5585 .. _RemoveSemicolon:
5587 **RemoveSemicolon** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <RemoveSemicolon>`
5588 Remove semicolons after the closing braces of functions and
5589 constructors/destructors.
5593 Setting this option to ``true`` could lead to incorrect code formatting
5594 due to clang-format's lack of complete semantic information. As such,
5595 extra care should be taken to review code changes made by this option.
5601 int max(int a, int b) { int max(int a, int b) {
5602 return a > b ? a : b; return a > b ? a : b;
5605 .. _RequiresClausePosition:
5607 **RequiresClausePosition** (``RequiresClausePositionStyle``) :versionbadge:`clang-format 15` :ref:`¶ <RequiresClausePosition>`
5608 The position of the ``requires`` clause.
5612 * ``RCPS_OwnLine`` (in configuration: ``OwnLine``)
5613 Always put the ``requires`` clause on its own line (possibly followed by
5618 template <typename T>
5622 template <typename T>
5626 template <typename T>
5630 template <typename T>
5635 * ``RCPS_OwnLineWithBrace`` (in configuration: ``OwnLineWithBrace``)
5636 As with ``OwnLine``, except, unless otherwise prohibited, place a
5637 following open brace (of a function definition) to follow on the same
5650 template <typename T>
5655 * ``RCPS_WithPreceding`` (in configuration: ``WithPreceding``)
5656 Try to put the clause together with the preceding part of a declaration.
5657 For class templates: stick to the template declaration.
5658 For function templates: stick to the template declaration.
5659 For function declaration followed by a requires clause: stick to the
5664 template <typename T> requires C<T>
5667 template <typename T> requires C<T>
5670 template <typename T>
5671 void baz(T t) requires C<T>
5674 * ``RCPS_WithFollowing`` (in configuration: ``WithFollowing``)
5675 Try to put the ``requires`` clause together with the class or function
5680 template <typename T>
5681 requires C<T> struct Foo {...
5683 template <typename T>
5684 requires C<T> void bar(T t) {...
5686 template <typename T>
5690 * ``RCPS_SingleLine`` (in configuration: ``SingleLine``)
5691 Try to put everything in the same line if possible. Otherwise normal
5692 line breaking rules take over.
5697 template <typename T> requires C<T> struct Foo {...
5699 template <typename T> requires C<T> void bar(T t) {...
5701 template <typename T> void bar(T t) requires C<T> {...
5703 // Not fitting, one possible example:
5704 template <typename LongName>
5705 requires C<LongName>
5708 template <typename LongName>
5709 requires C<LongName>
5710 void bar(LongName ln) {
5712 template <typename LongName>
5713 void bar(LongName ln)
5714 requires C<LongName> {
5718 .. _RequiresExpressionIndentation:
5720 **RequiresExpressionIndentation** (``RequiresExpressionIndentationKind``) :versionbadge:`clang-format 16` :ref:`¶ <RequiresExpressionIndentation>`
5721 The indentation used for requires expression bodies.
5725 * ``REI_OuterScope`` (in configuration: ``OuterScope``)
5726 Align requires expression body relative to the indentation level of the
5727 outer scope the requires expression resides in.
5728 This is the default.
5732 template <typename T>
5733 concept C = requires(T t) {
5737 * ``REI_Keyword`` (in configuration: ``Keyword``)
5738 Align requires expression body relative to the ``requires`` keyword.
5742 template <typename T>
5743 concept C = requires(T t) {
5749 .. _SeparateDefinitionBlocks:
5751 **SeparateDefinitionBlocks** (``SeparateDefinitionStyle``) :versionbadge:`clang-format 14` :ref:`¶ <SeparateDefinitionBlocks>`
5752 Specifies the use of empty lines to separate definition blocks, including
5753 classes, structs, enums, and functions.
5758 #include <cstring> #include <cstring>
5760 int a, b, c; struct Foo {
5764 public: namespace Ns {
5765 struct Foobar { class Bar {
5767 int b; struct Foobar {
5775 ITEM1, int method1() {
5778 template<typename T>
5779 int method2(T x) { enum List {
5783 int method3(int par) {
5784 // ... template<typename T>
5785 } int method2(T x) {
5791 int method3(int par) {
5801 * ``SDS_Leave`` (in configuration: ``Leave``)
5802 Leave definition blocks as they are.
5804 * ``SDS_Always`` (in configuration: ``Always``)
5805 Insert an empty line between definition blocks.
5807 * ``SDS_Never`` (in configuration: ``Never``)
5808 Remove any empty line between definition blocks.
5812 .. _ShortNamespaceLines:
5814 **ShortNamespaceLines** (``Unsigned``) :versionbadge:`clang-format 13` :ref:`¶ <ShortNamespaceLines>`
5815 The maximal number of unwrapped lines that a short namespace spans.
5818 This determines the maximum length of short namespaces by counting
5819 unwrapped lines (i.e. containing neither opening nor closing
5820 namespace brace) and makes ``FixNamespaceComments`` omit adding
5821 end comments for those.
5825 ShortNamespaceLines: 1 vs. ShortNamespaceLines: 0
5826 namespace a { namespace a {
5830 ShortNamespaceLines: 1 vs. ShortNamespaceLines: 0
5831 namespace b { namespace b {
5834 } // namespace b } // namespace b
5836 .. _SkipMacroDefinitionBody:
5838 **SkipMacroDefinitionBody** (``Boolean``) :versionbadge:`clang-format 18` :ref:`¶ <SkipMacroDefinitionBody>`
5839 Do not format macro definition body.
5843 **SortIncludes** (``SortIncludesOptions``) :versionbadge:`clang-format 3.8` :ref:`¶ <SortIncludes>`
5844 Controls if and how clang-format will sort ``#includes``.
5848 * ``SI_Never`` (in configuration: ``Never``)
5849 Includes are never sorted.
5859 * ``SI_CaseSensitive`` (in configuration: ``CaseSensitive``)
5860 Includes are sorted in an ASCIIbetical or case sensitive fashion.
5870 * ``SI_CaseInsensitive`` (in configuration: ``CaseInsensitive``)
5871 Includes are sorted in an alphabetical or case insensitive fashion.
5883 .. _SortJavaStaticImport:
5885 **SortJavaStaticImport** (``SortJavaStaticImportOptions``) :versionbadge:`clang-format 12` :ref:`¶ <SortJavaStaticImport>`
5886 When sorting Java imports, by default static imports are placed before
5887 non-static imports. If ``JavaStaticImportAfterImport`` is ``After``,
5888 static imports are placed after non-static imports.
5892 * ``SJSIO_Before`` (in configuration: ``Before``)
5893 Static imports are placed before non-static imports.
5895 .. code-block:: java
5897 import static org.example.function1;
5899 import org.example.ClassA;
5901 * ``SJSIO_After`` (in configuration: ``After``)
5902 Static imports are placed after non-static imports.
5904 .. code-block:: java
5906 import org.example.ClassA;
5908 import static org.example.function1;
5912 .. _SortUsingDeclarations:
5914 **SortUsingDeclarations** (``SortUsingDeclarationsOptions``) :versionbadge:`clang-format 5` :ref:`¶ <SortUsingDeclarations>`
5915 Controls if and how clang-format will sort using declarations.
5919 * ``SUD_Never`` (in configuration: ``Never``)
5920 Using declarations are never sorted.
5924 using std::chrono::duration_cast;
5927 using boost::regex_constants::icase;
5930 * ``SUD_Lexicographic`` (in configuration: ``Lexicographic``)
5931 Using declarations are sorted in the order defined as follows:
5932 Split the strings by ``::`` and discard any initial empty strings. Sort
5933 the lists of names lexicographically, and within those groups, names are
5934 in case-insensitive lexicographic order.
5939 using boost::regex_constants::icase;
5940 using std::chrono::duration_cast;
5944 * ``SUD_LexicographicNumeric`` (in configuration: ``LexicographicNumeric``)
5945 Using declarations are sorted in the order defined as follows:
5946 Split the strings by ``::`` and discard any initial empty strings. The
5947 last element of each list is a non-namespace name; all others are
5948 namespace names. Sort the lists of names lexicographically, where the
5949 sort order of individual names is that all non-namespace names come
5950 before all namespace names, and within those groups, names are in
5951 case-insensitive lexicographic order.
5956 using boost::regex_constants::icase;
5959 using std::chrono::duration_cast;
5963 .. _SpaceAfterCStyleCast:
5965 **SpaceAfterCStyleCast** (``Boolean``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceAfterCStyleCast>`
5966 If ``true``, a space is inserted after C style casts.
5971 (int) i; vs. (int)i;
5973 .. _SpaceAfterLogicalNot:
5975 **SpaceAfterLogicalNot** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <SpaceAfterLogicalNot>`
5976 If ``true``, a space is inserted after the logical not operator (``!``).
5981 ! someExpression(); vs. !someExpression();
5983 .. _SpaceAfterTemplateKeyword:
5985 **SpaceAfterTemplateKeyword** (``Boolean``) :versionbadge:`clang-format 4` :ref:`¶ <SpaceAfterTemplateKeyword>`
5986 If ``true``, a space will be inserted after the ``template`` keyword.
5991 template <int> void foo(); vs. template<int> void foo();
5993 .. _SpaceAroundPointerQualifiers:
5995 **SpaceAroundPointerQualifiers** (``SpaceAroundPointerQualifiersStyle``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceAroundPointerQualifiers>`
5996 Defines in which cases to put a space before or after pointer qualifiers
6000 * ``SAPQ_Default`` (in configuration: ``Default``)
6001 Don't ensure spaces around pointer qualifiers and use PointerAlignment
6006 PointerAlignment: Left PointerAlignment: Right
6007 void* const* x = NULL; vs. void *const *x = NULL;
6009 * ``SAPQ_Before`` (in configuration: ``Before``)
6010 Ensure that there is a space before pointer qualifiers.
6014 PointerAlignment: Left PointerAlignment: Right
6015 void* const* x = NULL; vs. void * const *x = NULL;
6017 * ``SAPQ_After`` (in configuration: ``After``)
6018 Ensure that there is a space after pointer qualifiers.
6022 PointerAlignment: Left PointerAlignment: Right
6023 void* const * x = NULL; vs. void *const *x = NULL;
6025 * ``SAPQ_Both`` (in configuration: ``Both``)
6026 Ensure that there is a space both before and after pointer qualifiers.
6030 PointerAlignment: Left PointerAlignment: Right
6031 void* const * x = NULL; vs. void * const *x = NULL;
6035 .. _SpaceBeforeAssignmentOperators:
6037 **SpaceBeforeAssignmentOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceBeforeAssignmentOperators>`
6038 If ``false``, spaces will be removed before assignment operators.
6043 int a = 5; vs. int a= 5;
6046 .. _SpaceBeforeCaseColon:
6048 **SpaceBeforeCaseColon** (``Boolean``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceBeforeCaseColon>`
6049 If ``false``, spaces will be removed before case colon.
6054 switch (x) { vs. switch (x) {
6055 case 1 : break; case 1: break;
6058 .. _SpaceBeforeCpp11BracedList:
6060 **SpaceBeforeCpp11BracedList** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCpp11BracedList>`
6061 If ``true``, a space will be inserted before a C++11 braced list
6062 used to initialize an object (after the preceding identifier or type).
6067 Foo foo { bar }; vs. Foo foo{ bar };
6069 vector<int> { 1, 2, 3 }; vector<int>{ 1, 2, 3 };
6070 new int[3] { 1, 2, 3 }; new int[3]{ 1, 2, 3 };
6072 .. _SpaceBeforeCtorInitializerColon:
6074 **SpaceBeforeCtorInitializerColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCtorInitializerColon>`
6075 If ``false``, spaces will be removed before constructor initializer
6081 Foo::Foo() : a(a) {} Foo::Foo(): a(a) {}
6083 .. _SpaceBeforeInheritanceColon:
6085 **SpaceBeforeInheritanceColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeInheritanceColon>`
6086 If ``false``, spaces will be removed before inheritance colon.
6091 class Foo : Bar {} vs. class Foo: Bar {}
6093 .. _SpaceBeforeJsonColon:
6095 **SpaceBeforeJsonColon** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <SpaceBeforeJsonColon>`
6096 If ``true``, a space will be added before a JSON colon. For other
6097 languages, e.g. JavaScript, use ``SpacesInContainerLiterals`` instead.
6103 "key" : "value" vs. "key": "value"
6106 .. _SpaceBeforeParens:
6108 **SpaceBeforeParens** (``SpaceBeforeParensStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceBeforeParens>`
6109 Defines in which cases to put a space before opening parentheses.
6113 * ``SBPO_Never`` (in configuration: ``Never``)
6114 This is **deprecated** and replaced by ``Custom`` below, with all
6115 ``SpaceBeforeParensOptions`` but ``AfterPlacementOperator`` set to
6118 * ``SBPO_ControlStatements`` (in configuration: ``ControlStatements``)
6119 Put a space before opening parentheses only after control statement
6120 keywords (``for/if/while...``).
6130 * ``SBPO_ControlStatementsExceptControlMacros`` (in configuration: ``ControlStatementsExceptControlMacros``)
6131 Same as ``SBPO_ControlStatements`` except this option doesn't apply to
6132 ForEach and If macros. This is useful in projects where ForEach/If
6133 macros are treated as function calls instead of control statements.
6134 ``SBPO_ControlStatementsExceptForEachMacros`` remains an alias for
6135 backward compatibility.
6145 * ``SBPO_NonEmptyParentheses`` (in configuration: ``NonEmptyParentheses``)
6146 Put a space before opening parentheses only if the parentheses are not
6158 * ``SBPO_Always`` (in configuration: ``Always``)
6159 Always put a space before opening parentheses, except when it's
6160 prohibited by the syntax rules (in function-like macro definitions) or
6161 when determined by other style rules (after unary operators, opening
6172 * ``SBPO_Custom`` (in configuration: ``Custom``)
6173 Configure each individual space before parentheses in
6174 ``SpaceBeforeParensOptions``.
6178 .. _SpaceBeforeParensOptions:
6180 **SpaceBeforeParensOptions** (``SpaceBeforeParensCustom``) :versionbadge:`clang-format 14` :ref:`¶ <SpaceBeforeParensOptions>`
6181 Control of individual space before parentheses.
6183 If ``SpaceBeforeParens`` is set to ``Custom``, use this to specify
6184 how each individual space before parentheses case should be handled.
6185 Otherwise, this is ignored.
6187 .. code-block:: yaml
6190 SpaceBeforeParens: Custom
6191 SpaceBeforeParensOptions:
6192 AfterControlStatements: true
6193 AfterFunctionDefinitionName: true
6195 Nested configuration flags:
6197 Precise control over the spacing before parentheses.
6201 # Should be declared this way:
6202 SpaceBeforeParens: Custom
6203 SpaceBeforeParensOptions:
6204 AfterControlStatements: true
6205 AfterFunctionDefinitionName: true
6207 * ``bool AfterControlStatements`` If ``true``, put space between control statement keywords
6208 (for/if/while...) and opening parentheses.
6213 if (...) {} vs. if(...) {}
6215 * ``bool AfterForeachMacros`` If ``true``, put space between foreach macros and opening parentheses.
6220 FOREACH (...) vs. FOREACH(...)
6221 <loop-body> <loop-body>
6223 * ``bool AfterFunctionDeclarationName`` If ``true``, put a space between function declaration name and opening
6229 void f (); vs. void f();
6231 * ``bool AfterFunctionDefinitionName`` If ``true``, put a space between function definition name and opening
6237 void f () {} vs. void f() {}
6239 * ``bool AfterIfMacros`` If ``true``, put space between if macros and opening parentheses.
6244 IF (...) vs. IF(...)
6245 <conditional-body> <conditional-body>
6247 * ``bool AfterOverloadedOperator`` If ``true``, put a space between operator overloading and opening
6253 void operator++ (int a); vs. void operator++(int a);
6254 object.operator++ (10); object.operator++(10);
6256 * ``bool AfterPlacementOperator`` If ``true``, put a space between operator ``new``/``delete`` and opening
6262 new (buf) T; vs. new(buf) T;
6263 delete (buf) T; delete(buf) T;
6265 * ``bool AfterRequiresInClause`` If ``true``, put space between requires keyword in a requires clause and
6266 opening parentheses, if there is one.
6271 template<typename T> vs. template<typename T>
6272 requires (A<T> && B<T>) requires(A<T> && B<T>)
6275 * ``bool AfterRequiresInExpression`` If ``true``, put space between requires keyword in a requires expression
6276 and opening parentheses.
6281 template<typename T> vs. template<typename T>
6282 concept C = requires (T t) { concept C = requires(T t) {
6286 * ``bool BeforeNonEmptyParentheses`` If ``true``, put a space before opening parentheses only if the
6287 parentheses are not empty.
6292 void f (int a); vs. void f();
6296 .. _SpaceBeforeRangeBasedForLoopColon:
6298 **SpaceBeforeRangeBasedForLoopColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeRangeBasedForLoopColon>`
6299 If ``false``, spaces will be removed before range-based for loop
6305 for (auto v : values) {} vs. for(auto v: values) {}
6307 .. _SpaceBeforeSquareBrackets:
6309 **SpaceBeforeSquareBrackets** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceBeforeSquareBrackets>`
6310 If ``true``, spaces will be before ``[``.
6311 Lambdas will not be affected. Only the first ``[`` will get a space added.
6316 int a [5]; vs. int a[5];
6317 int a [5][5]; vs. int a[5][5];
6319 .. _SpaceInEmptyBlock:
6321 **SpaceInEmptyBlock** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceInEmptyBlock>`
6322 If ``true``, spaces will be inserted into ``{}``.
6327 void f() { } vs. void f() {}
6328 while (true) { } while (true) {}
6330 .. _SpaceInEmptyParentheses:
6332 **SpaceInEmptyParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceInEmptyParentheses>`
6333 If ``true``, spaces may be inserted into ``()``.
6334 This option is **deprecated**. See ``InEmptyParentheses`` of
6335 ``SpacesInParensOptions``.
6337 .. _SpacesBeforeTrailingComments:
6339 **SpacesBeforeTrailingComments** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesBeforeTrailingComments>`
6340 The number of spaces before trailing line comments
6341 (``//`` - comments).
6343 This does not affect trailing block comments (``/*`` - comments) as those
6344 commonly have different usage patterns and a number of special cases. In
6345 the case of Verilog, it doesn't affect a comment right after the opening
6346 parenthesis in the port or parameter list in a module header, because it
6347 is probably for the port on the following line instead of the parenthesis
6352 SpacesBeforeTrailingComments: 3
6361 **SpacesInAngles** (``SpacesInAnglesStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ <SpacesInAngles>`
6362 The SpacesInAnglesStyle to use for template argument lists.
6366 * ``SIAS_Never`` (in configuration: ``Never``)
6367 Remove spaces after ``<`` and before ``>``.
6371 static_cast<int>(arg);
6372 std::function<void(int)> fct;
6374 * ``SIAS_Always`` (in configuration: ``Always``)
6375 Add spaces after ``<`` and before ``>``.
6379 static_cast< int >(arg);
6380 std::function< void(int) > fct;
6382 * ``SIAS_Leave`` (in configuration: ``Leave``)
6383 Keep a single space after ``<`` and before ``>`` if any spaces were
6384 present. Option ``Standard: Cpp03`` takes precedence.
6388 .. _SpacesInCStyleCastParentheses:
6390 **SpacesInCStyleCastParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInCStyleCastParentheses>`
6391 If ``true``, spaces may be inserted into C style casts.
6392 This option is **deprecated**. See ``InCStyleCasts`` of
6393 ``SpacesInParensOptions``.
6395 .. _SpacesInConditionalStatement:
6397 **SpacesInConditionalStatement** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpacesInConditionalStatement>`
6398 If ``true``, spaces will be inserted around if/for/switch/while
6400 This option is **deprecated**. See ``InConditionalStatements`` of
6401 ``SpacesInParensOptions``.
6403 .. _SpacesInContainerLiterals:
6405 **SpacesInContainerLiterals** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInContainerLiterals>`
6406 If ``true``, spaces are inserted inside container literals (e.g. ObjC and
6407 Javascript array and dict literals). For JSON, use
6408 ``SpaceBeforeJsonColon`` instead.
6413 var arr = [ 1, 2, 3 ]; vs. var arr = [1, 2, 3];
6414 f({a : 1, b : 2, c : 3}); f({a: 1, b: 2, c: 3});
6416 .. _SpacesInLineCommentPrefix:
6418 **SpacesInLineCommentPrefix** (``SpacesInLineComment``) :versionbadge:`clang-format 13` :ref:`¶ <SpacesInLineCommentPrefix>`
6419 How many spaces are allowed at the start of a line comment. To disable the
6420 maximum set it to ``-1``, apart from that the maximum takes precedence
6427 // One space is forced
6429 // but more spaces are possible
6433 //Forces to start every comment directly after the slashes
6435 Note that in line comment sections the relative indent of the subsequent
6436 lines is kept, that means the following:
6442 //if (b) { // if (b) {
6443 // return true; // return true;
6451 This option has only effect if ``ReflowComments`` is set to ``true``.
6453 Nested configuration flags:
6455 Control of spaces within a single line comment.
6457 * ``unsigned Minimum`` The minimum number of spaces at the start of the comment.
6459 * ``unsigned Maximum`` The maximum number of spaces at the start of the comment.
6464 **SpacesInParens** (``SpacesInParensStyle``) :versionbadge:`clang-format 17` :ref:`¶ <SpacesInParens>`
6465 Defines in which cases spaces will be inserted after ``(`` and before
6470 * ``SIPO_Never`` (in configuration: ``Never``)
6471 Never put a space in parentheses.
6481 * ``SIPO_Custom`` (in configuration: ``Custom``)
6482 Configure each individual space in parentheses in
6483 `SpacesInParensOptions`.
6487 .. _SpacesInParensOptions:
6489 **SpacesInParensOptions** (``SpacesInParensCustom``) :versionbadge:`clang-format 17` :ref:`¶ <SpacesInParensOptions>`
6490 Control of individual spaces in parentheses.
6492 If ``SpacesInParens`` is set to ``Custom``, use this to specify
6493 how each individual space in parentheses case should be handled.
6494 Otherwise, this is ignored.
6496 .. code-block:: yaml
6499 SpacesInParens: Custom
6500 SpacesInParensOptions:
6501 ExceptDoubleParentheses: false
6502 InConditionalStatements: true
6503 InEmptyParentheses: true
6505 Nested configuration flags:
6507 Precise control over the spacing in parentheses.
6511 # Should be declared this way:
6512 SpacesInParens: Custom
6513 SpacesInParensOptions:
6514 ExceptDoubleParentheses: false
6515 InConditionalStatements: true
6518 * ``bool ExceptDoubleParentheses`` Override any of the following options to prevent addition of space
6519 when both opening and closing parentheses use multiple parentheses.
6524 __attribute__(( noreturn ))
6528 Uses the applicable option.
6530 * ``bool InConditionalStatements`` Put a space in parentheses only inside conditional statements
6531 (``for/if/while/switch...``).
6536 if ( a ) { ... } vs. if (a) { ... }
6537 while ( i < 5 ) { ... } while (i < 5) { ... }
6539 * ``bool InCStyleCasts`` Put a space in C style casts.
6544 x = ( int32 )y vs. x = (int32)y
6545 y = (( int (*)(int) )foo)(x); y = ((int (*)(int))foo)(x);
6547 * ``bool InEmptyParentheses`` Insert a space in empty parentheses, i.e. ``()``.
6552 void f( ) { vs. void f() {
6553 int x[] = {foo( ), bar( )}; int x[] = {foo(), bar()};
6554 if (true) { if (true) {
6559 * ``bool Other`` Put a space in parentheses not covered by preceding options.
6564 t f( Deleted & ) & = delete; vs. t f(Deleted &) & = delete;
6567 .. _SpacesInParentheses:
6569 **SpacesInParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInParentheses>`
6570 If ``true``, spaces will be inserted after ``(`` and before ``)``.
6571 This option is **deprecated**. The previous behavior is preserved by using
6572 ``SpacesInParens`` with ``Custom`` and by setting all
6573 ``SpacesInParensOptions`` to ``true`` except for ``InCStyleCasts`` and
6574 ``InEmptyParentheses``.
6576 .. _SpacesInSquareBrackets:
6578 **SpacesInSquareBrackets** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInSquareBrackets>`
6579 If ``true``, spaces will be inserted after ``[`` and before ``]``.
6580 Lambdas without arguments or unspecified size array declarations will not
6586 int a[ 5 ]; vs. int a[5];
6587 std::unique_ptr<int[]> foo() {} // Won't be affected
6591 **Standard** (``LanguageStandard``) :versionbadge:`clang-format 3.7` :ref:`¶ <Standard>`
6592 Parse and format C++ constructs compatible with this standard.
6597 vector<set<int> > x; vs. vector<set<int>> x;
6601 * ``LS_Cpp03`` (in configuration: ``c++03``)
6602 Parse and format as C++03.
6603 ``Cpp03`` is a deprecated alias for ``c++03``
6605 * ``LS_Cpp11`` (in configuration: ``c++11``)
6606 Parse and format as C++11.
6608 * ``LS_Cpp14`` (in configuration: ``c++14``)
6609 Parse and format as C++14.
6611 * ``LS_Cpp17`` (in configuration: ``c++17``)
6612 Parse and format as C++17.
6614 * ``LS_Cpp20`` (in configuration: ``c++20``)
6615 Parse and format as C++20.
6617 * ``LS_Latest`` (in configuration: ``Latest``)
6618 Parse and format using the latest supported language version.
6619 ``Cpp11`` is a deprecated alias for ``Latest``
6621 * ``LS_Auto`` (in configuration: ``Auto``)
6622 Automatic detection based on the input.
6626 .. _StatementAttributeLikeMacros:
6628 **StatementAttributeLikeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <StatementAttributeLikeMacros>`
6629 Macros which are ignored in front of a statement, as if they were an
6630 attribute. So that they are not parsed as identifier, for example for Qts
6635 AlignConsecutiveDeclarations: true
6636 StatementAttributeLikeMacros: []
6637 unsigned char data = 'x';
6638 emit signal(data); // This is parsed as variable declaration.
6640 AlignConsecutiveDeclarations: true
6641 StatementAttributeLikeMacros: [emit]
6642 unsigned char data = 'x';
6643 emit signal(data); // Now it's fine again.
6645 .. _StatementMacros:
6647 **StatementMacros** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <StatementMacros>`
6648 A vector of macros that should be interpreted as complete
6651 Typical macros are expressions, and require a semi-colon to be
6652 added; sometimes this is not the case, and this allows to make
6653 clang-format aware of such cases.
6655 For example: Q_UNUSED
6659 **TabWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <TabWidth>`
6660 The number of columns used for tab stops.
6662 .. _TableGenBreakInsideDAGArg:
6664 **TableGenBreakInsideDAGArg** (``DAGArgStyle``) :versionbadge:`clang-format 19` :ref:`¶ <TableGenBreakInsideDAGArg>`
6665 The styles of the line break inside the DAGArg in TableGen.
6669 * ``DAS_DontBreak`` (in configuration: ``DontBreak``)
6670 Never break inside DAGArg.
6674 let DAGArgIns = (ins i32:$src1, i32:$src2);
6676 * ``DAS_BreakElements`` (in configuration: ``BreakElements``)
6677 Break inside DAGArg after each list element but for the last.
6678 This aligns to the first element.
6682 let DAGArgIns = (ins i32:$src1,
6685 * ``DAS_BreakAll`` (in configuration: ``BreakAll``)
6686 Break inside DAGArg after the operator and the all elements.
6690 let DAGArgIns = (ins
6697 .. _TableGenBreakingDAGArgOperators:
6699 **TableGenBreakingDAGArgOperators** (``List of Strings``) :versionbadge:`clang-format 19` :ref:`¶ <TableGenBreakingDAGArgOperators>`
6700 Works only when TableGenBreakInsideDAGArg is not DontBreak.
6701 The string list needs to consist of identifiers in TableGen.
6702 If any identifier is specified, this limits the line breaks by
6703 TableGenBreakInsideDAGArg option only on DAGArg values beginning with
6704 the specified identifiers.
6706 For example the configuration,
6708 .. code-block:: yaml
6710 TableGenBreakInsideDAGArg: BreakAll
6711 TableGenBreakingDAGArgOperators: [ins, outs]
6713 makes the line break only occurs inside DAGArgs beginning with the
6714 specified identifiers ``ins`` and ``outs``.
6719 let DAGArgIns = (ins
6723 let DAGArgOtherID = (other i32:$other1, i32:$other2);
6724 let DAGArgBang = (!cast<SomeType>("Some") i32:$src1, i32:$src2)
6728 **TemplateNames** (``List of Strings``) :versionbadge:`clang-format 20` :ref:`¶ <TemplateNames>`
6729 A vector of non-keyword identifiers that should be interpreted as
6732 A ``<`` after a template name is annotated as a template opener instead of
6737 **TypeNames** (``List of Strings``) :versionbadge:`clang-format 17` :ref:`¶ <TypeNames>`
6738 A vector of non-keyword identifiers that should be interpreted as type
6741 A ``*``, ``&``, or ``&&`` between a type name and another non-keyword
6742 identifier is annotated as a pointer or reference token instead of a
6747 **TypenameMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <TypenameMacros>`
6748 A vector of macros that should be interpreted as type declarations
6749 instead of as function calls.
6751 These are expected to be macros of the form:
6757 In the .clang-format configuration file, this can be configured like:
6759 .. code-block:: yaml
6761 TypenameMacros: [STACK_OF, LIST]
6763 For example: OpenSSL STACK_OF, BSD LIST_ENTRY.
6767 **UseCRLF** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <UseCRLF>`
6768 This option is **deprecated**. See ``LF`` and ``CRLF`` of ``LineEnding``.
6772 **UseTab** (``UseTabStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <UseTab>`
6773 The way to use tab characters in the resulting file.
6777 * ``UT_Never`` (in configuration: ``Never``)
6780 * ``UT_ForIndentation`` (in configuration: ``ForIndentation``)
6781 Use tabs only for indentation.
6783 * ``UT_ForContinuationAndIndentation`` (in configuration: ``ForContinuationAndIndentation``)
6784 Fill all leading whitespace with tabs, and use spaces for alignment that
6785 appears within a line (e.g. consecutive assignments and declarations).
6787 * ``UT_AlignWithSpaces`` (in configuration: ``AlignWithSpaces``)
6788 Use tabs for line continuation and indentation, and spaces for
6791 * ``UT_Always`` (in configuration: ``Always``)
6792 Use tabs whenever we need to fill whitespace that spans at least from
6793 one tab stop to the next one.
6797 .. _VerilogBreakBetweenInstancePorts:
6799 **VerilogBreakBetweenInstancePorts** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <VerilogBreakBetweenInstancePorts>`
6800 For Verilog, put each port on its own line in module instantiations.
6811 ffnand ff1(.q(), .qbar(out1), .clear(in1), .preset(in2));
6813 .. _WhitespaceSensitiveMacros:
6815 **WhitespaceSensitiveMacros** (``List of Strings``) :versionbadge:`clang-format 11` :ref:`¶ <WhitespaceSensitiveMacros>`
6816 A vector of macros which are whitespace-sensitive and should not
6819 These are expected to be macros of the form:
6825 In the .clang-format configuration file, this can be configured like:
6827 .. code-block:: yaml
6829 WhitespaceSensitiveMacros: [STRINGIZE, PP_STRINGIZE]
6831 For example: BOOST_PP_STRINGIZE
6833 .. END_FORMAT_STYLE_OPTIONS
6835 Adding additional style options
6836 ===============================
6838 Each additional style option adds costs to the clang-format project. Some of
6839 these costs affect the clang-format development itself, as we need to make
6840 sure that any given combination of options work and that new features don't
6841 break any of the existing options in any way. There are also costs for end users
6842 as options become less discoverable and people have to think about and make a
6843 decision on options they don't really care about.
6845 The goal of the clang-format project is more on the side of supporting a
6846 limited set of styles really well as opposed to supporting every single style
6847 used by a codebase somewhere in the wild. Of course, we do want to support all
6848 major projects and thus have established the following bar for adding style
6849 options. Each new style option must:
6851 * be used in a project of significant size (have dozens of contributors)
6852 * have a publicly accessible style guide
6853 * have a person willing to contribute and maintain patches
6858 A style similar to the `Linux Kernel style
6859 <https://www.kernel.org/doc/html/latest/process/coding-style.html>`_:
6861 .. code-block:: yaml
6866 BreakBeforeBraces: Linux
6867 AllowShortIfStatementsOnASingleLine: false
6868 IndentCaseLabels: false
6870 The result is (imagine that tabs are used for indentation here):
6882 do_something_else();
6888 do_something_completely_different();
6899 A style similar to the default Visual Studio formatting style:
6901 .. code-block:: yaml
6905 BreakBeforeBraces: Allman
6906 AllowShortIfStatementsOnASingleLine: false
6907 IndentCaseLabels: false
6923 do_something_else();
6929 do_something_completely_different();