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:
314 - AcrossEmptyLinesAndComments
316 For example, to align across empty lines and not across comments, either
321 AlignConsecutiveMacros: AcrossEmptyLines
323 AlignConsecutiveMacros:
325 AcrossEmptyLines: true
326 AcrossComments: false
328 * ``bool Enabled`` Whether aligning is enabled.
332 #define SHORT_NAME 42
333 #define LONGER_NAME 0x007f
334 #define EVEN_LONGER_NAME (2)
335 #define foo(x) (x * x)
336 #define bar(y, z) (y + z)
339 int somelongname = 2;
350 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
356 int somelongname = 2;
363 int somelongname = 2;
368 * ``bool AcrossComments`` Whether to align across comments.
382 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
383 like ``+=`` are aligned along with ``=``.
395 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
396 operators are left-padded to the same length as long ones in order to
397 put all assignment operators to the right of the left hand side.
416 .. _AlignConsecutiveBitFields:
418 **AlignConsecutiveBitFields** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 11` :ref:`¶ <AlignConsecutiveBitFields>`
419 Style of aligning consecutive bit fields.
421 ``Consecutive`` will align the bitfield separators of consecutive lines.
422 This will result in formattings like:
430 Nested configuration flags:
434 They can also be read as a whole for compatibility. The choices are:
439 - AcrossEmptyLinesAndComments
441 For example, to align across empty lines and not across comments, either
446 AlignConsecutiveMacros: AcrossEmptyLines
448 AlignConsecutiveMacros:
450 AcrossEmptyLines: true
451 AcrossComments: false
453 * ``bool Enabled`` Whether aligning is enabled.
457 #define SHORT_NAME 42
458 #define LONGER_NAME 0x007f
459 #define EVEN_LONGER_NAME (2)
460 #define foo(x) (x * x)
461 #define bar(y, z) (y + z)
464 int somelongname = 2;
475 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
481 int somelongname = 2;
488 int somelongname = 2;
493 * ``bool AcrossComments`` Whether to align across comments.
507 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
508 like ``+=`` are aligned along with ``=``.
520 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
521 operators are left-padded to the same length as long ones in order to
522 put all assignment operators to the right of the left hand side.
541 .. _AlignConsecutiveDeclarations:
543 **AlignConsecutiveDeclarations** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignConsecutiveDeclarations>`
544 Style of aligning consecutive declarations.
546 ``Consecutive`` will align the declaration names of consecutive lines.
547 This will result in formattings like:
555 Nested configuration flags:
559 They can also be read as a whole for compatibility. The choices are:
564 - AcrossEmptyLinesAndComments
566 For example, to align across empty lines and not across comments, either
571 AlignConsecutiveMacros: AcrossEmptyLines
573 AlignConsecutiveMacros:
575 AcrossEmptyLines: true
576 AcrossComments: false
578 * ``bool Enabled`` Whether aligning is enabled.
582 #define SHORT_NAME 42
583 #define LONGER_NAME 0x007f
584 #define EVEN_LONGER_NAME (2)
585 #define foo(x) (x * x)
586 #define bar(y, z) (y + z)
589 int somelongname = 2;
600 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
606 int somelongname = 2;
613 int somelongname = 2;
618 * ``bool AcrossComments`` Whether to align across comments.
632 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
633 like ``+=`` are aligned along with ``=``.
645 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
646 operators are left-padded to the same length as long ones in order to
647 put all assignment operators to the right of the left hand side.
666 .. _AlignConsecutiveMacros:
668 **AlignConsecutiveMacros** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AlignConsecutiveMacros>`
669 Style of aligning consecutive macro definitions.
671 ``Consecutive`` will result in formattings like:
675 #define SHORT_NAME 42
676 #define LONGER_NAME 0x007f
677 #define EVEN_LONGER_NAME (2)
678 #define foo(x) (x * x)
679 #define bar(y, z) (y + z)
681 Nested configuration flags:
685 They can also be read as a whole for compatibility. The choices are:
690 - AcrossEmptyLinesAndComments
692 For example, to align across empty lines and not across comments, either
697 AlignConsecutiveMacros: AcrossEmptyLines
699 AlignConsecutiveMacros:
701 AcrossEmptyLines: true
702 AcrossComments: false
704 * ``bool Enabled`` Whether aligning is enabled.
708 #define SHORT_NAME 42
709 #define LONGER_NAME 0x007f
710 #define EVEN_LONGER_NAME (2)
711 #define foo(x) (x * x)
712 #define bar(y, z) (y + z)
715 int somelongname = 2;
726 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
732 int somelongname = 2;
739 int somelongname = 2;
744 * ``bool AcrossComments`` Whether to align across comments.
758 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
759 like ``+=`` are aligned along with ``=``.
771 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
772 operators are left-padded to the same length as long ones in order to
773 put all assignment operators to the right of the left hand side.
792 .. _AlignConsecutiveShortCaseStatements:
794 **AlignConsecutiveShortCaseStatements** (``ShortCaseStatementsAlignmentStyle``) :versionbadge:`clang-format 17` :ref:`¶ <AlignConsecutiveShortCaseStatements>`
795 Style of aligning consecutive short case labels.
796 Only applies if ``AllowShortCaseLabelsOnASingleLine`` is ``true``.
802 AlignConsecutiveShortCaseStatements:
804 AcrossEmptyLines: true
806 AlignCaseColons: false
808 Nested configuration flags:
812 * ``bool Enabled`` Whether aligning is enabled.
818 case log::info: return "info:";
819 case log::warning: return "warning:";
825 case log::info: return "info:";
826 case log::warning: return "warning:";
830 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
836 case log::info: return "info:";
837 case log::warning: return "warning:";
844 case log::info: return "info:";
845 case log::warning: return "warning:";
850 * ``bool AcrossComments`` Whether to align across comments.
856 case log::info: return "info:";
857 case log::warning: return "warning:";
864 case log::info: return "info:";
865 case log::warning: return "warning:";
870 * ``bool AlignCaseColons`` Whether aligned case labels are aligned on the colon, or on the
871 , or on the tokens after the colon.
877 case log::info : return "info:";
878 case log::warning: return "warning:";
884 case log::info: return "info:";
885 case log::warning: return "warning:";
890 .. _AlignEscapedNewlines:
892 **AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) :versionbadge:`clang-format 5` :ref:`¶ <AlignEscapedNewlines>`
893 Options for aligning backslashes in escaped newlines.
897 * ``ENAS_DontAlign`` (in configuration: ``DontAlign``)
898 Don't align escaped newlines.
907 * ``ENAS_Left`` (in configuration: ``Left``)
908 Align escaped newlines as far left as possible.
920 * ``ENAS_Right`` (in configuration: ``Right``)
921 Align escaped newlines in the right-most column.
934 **AlignOperands** (``OperandAlignmentStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AlignOperands>`
935 If ``true``, horizontally align operands of binary and ternary
940 * ``OAS_DontAlign`` (in configuration: ``DontAlign``)
941 Do not align operands of binary and ternary expressions.
942 The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
943 the start of the line.
945 * ``OAS_Align`` (in configuration: ``Align``)
946 Horizontally align operands of binary and ternary expressions.
948 Specifically, this aligns operands of a single expression that needs
949 to be split over multiple lines, e.g.:
953 int aaa = bbbbbbbbbbbbbbb +
956 When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
957 aligned with the operand on the first line.
961 int aaa = bbbbbbbbbbbbbbb
964 * ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
965 Horizontally align operands of binary and ternary expressions.
967 This is similar to ``AO_Align``, except when
968 ``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
969 that the wrapped operand is aligned with the operand on the first line.
973 int aaa = bbbbbbbbbbbbbbb
978 .. _AlignTrailingComments:
980 **AlignTrailingComments** (``TrailingCommentsAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlignTrailingComments>`
981 Control of trailing comments.
983 The alignment stops at closing braces after a line break, and only
984 followed by other closing braces, a (``do-``) ``while``, a lambda call, or
990 As of clang-format 16 this option is not a bool but can be set
991 to the options. Conventional bool options still can be parsed as before.
997 AlignTrailingComments:
1001 Nested configuration flags:
1005 * ``TrailingCommentsAlignmentKinds Kind``
1006 Specifies the way to align trailing comments.
1010 * ``TCAS_Leave`` (in configuration: ``Leave``)
1011 Leave trailing comments as they are.
1019 int abcd; // comment
1021 * ``TCAS_Always`` (in configuration: ``Always``)
1022 Align trailing comments.
1030 int abcd; // comment
1032 * ``TCAS_Never`` (in configuration: ``Never``)
1033 Don't align trailing comments but other formatter applies.
1041 int abcd; // comment
1044 * ``unsigned OverEmptyLines`` How many empty lines to apply alignment.
1045 When both ``MaxEmptyLinesToKeep`` and ``OverEmptyLines`` are set to 2,
1046 it formats like below.
1052 int ab; // comments are
1055 int abcdef; // aligned
1057 When ``MaxEmptyLinesToKeep`` is set to 2 and ``OverEmptyLines`` is set
1058 to 1, it formats like below.
1067 int abcdef; // but this isn't
1070 .. _AllowAllArgumentsOnNextLine:
1072 **AllowAllArgumentsOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllArgumentsOnNextLine>`
1073 If a function call or braced initializer list doesn't fit on a
1074 line, allow putting all arguments onto the next line, even if
1075 ``BinPackArguments`` is ``false``.
1089 .. _AllowAllConstructorInitializersOnNextLine:
1091 **AllowAllConstructorInitializersOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllConstructorInitializersOnNextLine>`
1092 This option is **deprecated**. See ``NextLine`` of
1093 ``PackConstructorInitializers``.
1095 .. _AllowAllParametersOfDeclarationOnNextLine:
1097 **AllowAllParametersOfDeclarationOnNextLine** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowAllParametersOfDeclarationOnNextLine>`
1098 If the function declaration doesn't fit on a line,
1099 allow putting all parameters of a function declaration onto
1100 the next line even if ``BinPackParameters`` is ``false``.
1106 int a, int b, int c, int d, int e);
1109 void myFunction(int a,
1115 .. _AllowBreakBeforeNoexceptSpecifier:
1117 **AllowBreakBeforeNoexceptSpecifier** (``BreakBeforeNoexceptSpecifierStyle``) :versionbadge:`clang-format 18` :ref:`¶ <AllowBreakBeforeNoexceptSpecifier>`
1118 Controls if there could be a line break before a ``noexcept`` specifier.
1122 * ``BBNSS_Never`` (in configuration: ``Never``)
1123 No line break allowed.
1128 double arg2) noexcept;
1130 void bar(int arg1, double arg2) noexcept(
1131 noexcept(baz(arg1)) &&
1132 noexcept(baz(arg2)));
1134 * ``BBNSS_OnlyWithParen`` (in configuration: ``OnlyWithParen``)
1135 For a simple ``noexcept`` there is no line break allowed, but when we
1136 have a condition it is.
1141 double arg2) noexcept;
1143 void bar(int arg1, double arg2)
1144 noexcept(noexcept(baz(arg1)) &&
1145 noexcept(baz(arg2)));
1147 * ``BBNSS_Always`` (in configuration: ``Always``)
1148 Line breaks are allowed. But note that because of the associated
1149 penalties ``clang-format`` often prefers not to break before the
1155 double arg2) noexcept;
1157 void bar(int arg1, double arg2)
1158 noexcept(noexcept(baz(arg1)) &&
1159 noexcept(baz(arg2)));
1163 .. _AllowShortBlocksOnASingleLine:
1165 **AllowShortBlocksOnASingleLine** (``ShortBlockStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortBlocksOnASingleLine>`
1166 Dependent on the value, ``while (true) { continue; }`` can be put on a
1171 * ``SBS_Never`` (in configuration: ``Never``)
1172 Never merge blocks into a single line.
1182 * ``SBS_Empty`` (in configuration: ``Empty``)
1183 Only merge empty blocks.
1192 * ``SBS_Always`` (in configuration: ``Always``)
1193 Always merge short blocks into a single line.
1198 while (true) { continue; }
1202 .. _AllowShortCaseLabelsOnASingleLine:
1204 **AllowShortCaseLabelsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.6` :ref:`¶ <AllowShortCaseLabelsOnASingleLine>`
1205 If ``true``, short case labels will be contracted to a single line.
1210 switch (a) { vs. switch (a) {
1211 case 1: x = 1; break; case 1:
1212 case 2: return; x = 1;
1218 .. _AllowShortCompoundRequirementOnASingleLine:
1220 **AllowShortCompoundRequirementOnASingleLine** (``Boolean``) :versionbadge:`clang-format 18` :ref:`¶ <AllowShortCompoundRequirementOnASingleLine>`
1221 Allow short compound requirement on a single line.
1226 template <typename T>
1227 concept c = requires(T x) {
1228 { x + 1 } -> std::same_as<int>;
1232 template <typename T>
1233 concept c = requires(T x) {
1236 } -> std::same_as<int>;
1239 .. _AllowShortEnumsOnASingleLine:
1241 **AllowShortEnumsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <AllowShortEnumsOnASingleLine>`
1242 Allow short enums on a single line.
1247 enum { A, B } myEnum;
1255 .. _AllowShortFunctionsOnASingleLine:
1257 **AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortFunctionsOnASingleLine>`
1258 Dependent on the value, ``int f() { return 0; }`` can be put on a
1263 * ``SFS_None`` (in configuration: ``None``)
1264 Never merge functions into a single line.
1266 * ``SFS_InlineOnly`` (in configuration: ``InlineOnly``)
1267 Only merge functions defined inside a class. Same as "inline",
1268 except it does not implies "empty": i.e. top level empty functions
1269 are not merged either.
1282 * ``SFS_Empty`` (in configuration: ``Empty``)
1283 Only merge empty functions.
1292 * ``SFS_Inline`` (in configuration: ``Inline``)
1293 Only merge functions defined inside a class. Implies "empty".
1305 * ``SFS_All`` (in configuration: ``All``)
1306 Merge all functions fitting on a single line.
1317 .. _AllowShortIfStatementsOnASingleLine:
1319 **AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowShortIfStatementsOnASingleLine>`
1320 Dependent on the value, ``if (a) return;`` can be put on a single line.
1324 * ``SIS_Never`` (in configuration: ``Never``)
1325 Never put short ifs on the same line.
1343 * ``SIS_WithoutElse`` (in configuration: ``WithoutElse``)
1344 Put short ifs on the same line only if there is no else statement.
1361 * ``SIS_OnlyFirstIf`` (in configuration: ``OnlyFirstIf``)
1362 Put short ifs, but not else ifs nor else statements, on the same line.
1379 * ``SIS_AllIfsAndElse`` (in configuration: ``AllIfsAndElse``)
1380 Always put short ifs, else ifs and else statements on the same
1397 .. _AllowShortLambdasOnASingleLine:
1399 **AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AllowShortLambdasOnASingleLine>`
1400 Dependent on the value, ``auto lambda []() { return 0; }`` can be put on a
1405 * ``SLS_None`` (in configuration: ``None``)
1406 Never merge lambdas into a single line.
1408 * ``SLS_Empty`` (in configuration: ``Empty``)
1409 Only merge empty lambdas.
1413 auto lambda = [](int a) {};
1414 auto lambda2 = [](int a) {
1418 * ``SLS_Inline`` (in configuration: ``Inline``)
1419 Merge lambda into a single line if the lambda is argument of a function.
1423 auto lambda = [](int x, int y) {
1426 sort(a.begin(), a.end(), [](int x, int y) { return x < y; });
1428 * ``SLS_All`` (in configuration: ``All``)
1429 Merge all lambdas fitting on a single line.
1433 auto lambda = [](int a) {};
1434 auto lambda2 = [](int a) { return a; };
1438 .. _AllowShortLoopsOnASingleLine:
1440 **AllowShortLoopsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <AllowShortLoopsOnASingleLine>`
1441 If ``true``, ``while (true) continue;`` can be put on a single
1444 .. _AlwaysBreakAfterDefinitionReturnType:
1446 **AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlwaysBreakAfterDefinitionReturnType>`
1447 The function definition return type breaking style to use. This
1448 option is **deprecated** and is retained for backwards compatibility.
1452 * ``DRTBS_None`` (in configuration: ``None``)
1453 Break after return type automatically.
1454 ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
1456 * ``DRTBS_All`` (in configuration: ``All``)
1457 Always break after the return type.
1459 * ``DRTBS_TopLevel`` (in configuration: ``TopLevel``)
1460 Always break after the return types of top-level functions.
1464 .. _AlwaysBreakAfterReturnType:
1466 **AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlwaysBreakAfterReturnType>`
1467 The function declaration return type breaking style to use.
1471 * ``RTBS_None`` (in configuration: ``None``)
1472 Break after return type automatically.
1473 ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
1478 int f() { return 0; };
1481 int f() { return 1; }
1483 * ``RTBS_All`` (in configuration: ``All``)
1484 Always break after the return type.
1501 * ``RTBS_TopLevel`` (in configuration: ``TopLevel``)
1502 Always break after the return types of top-level functions.
1507 int f() { return 0; };
1516 * ``RTBS_AllDefinitions`` (in configuration: ``AllDefinitions``)
1517 Always break after the return type of function definitions.
1533 * ``RTBS_TopLevelDefinitions`` (in configuration: ``TopLevelDefinitions``)
1534 Always break after the return type of top-level definitions.
1539 int f() { return 0; };
1549 .. _AlwaysBreakBeforeMultilineStrings:
1551 **AlwaysBreakBeforeMultilineStrings** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakBeforeMultilineStrings>`
1552 If ``true``, always break before multiline string literals.
1554 This flag is mean to make cases where there are multiple multiline strings
1555 in a file look more consistent. Thus, it will only take effect if wrapping
1556 the string at that point leads to it being indented
1557 ``ContinuationIndentWidth`` spaces from the start of the line.
1562 aaaa = vs. aaaa = "bbbb"
1566 .. _AlwaysBreakTemplateDeclarations:
1568 **AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakTemplateDeclarations>`
1569 The template declaration breaking style to use.
1573 * ``BTDS_No`` (in configuration: ``No``)
1574 Do not force break before declaration.
1575 ``PenaltyBreakTemplateDeclaration`` is taken into account.
1579 template <typename T> T foo() {
1581 template <typename T> T foo(int aaaaaaaaaaaaaaaaaaaaa,
1582 int bbbbbbbbbbbbbbbbbbbbb) {
1585 * ``BTDS_MultiLine`` (in configuration: ``MultiLine``)
1586 Force break after template declaration only when the following
1587 declaration spans multiple lines.
1591 template <typename T> T foo() {
1593 template <typename T>
1594 T foo(int aaaaaaaaaaaaaaaaaaaaa,
1595 int bbbbbbbbbbbbbbbbbbbbb) {
1598 * ``BTDS_Yes`` (in configuration: ``Yes``)
1599 Always break after template declaration.
1603 template <typename T>
1606 template <typename T>
1607 T foo(int aaaaaaaaaaaaaaaaaaaaa,
1608 int bbbbbbbbbbbbbbbbbbbbb) {
1613 .. _AttributeMacros:
1615 **AttributeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <AttributeMacros>`
1616 A vector of strings that should be interpreted as attributes/qualifiers
1617 instead of identifiers. This can be useful for language extensions or
1618 static analyzer annotations.
1624 x = (char *__capability)&y;
1625 int function(void) __unused;
1626 void only_writes_to_buffer(char *__output buffer);
1628 In the .clang-format configuration file, this can be configured like:
1630 .. code-block:: yaml
1632 AttributeMacros: ['__capability', '__output', '__unused']
1634 .. _BinPackArguments:
1636 **BinPackArguments** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackArguments>`
1637 If ``false``, a function call's arguments will either be all on the
1638 same line or will have one line each.
1644 f(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa,
1645 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
1650 f(aaaaaaaaaaaaaaaaaaaa,
1651 aaaaaaaaaaaaaaaaaaaa,
1652 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
1655 .. _BinPackParameters:
1657 **BinPackParameters** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackParameters>`
1658 If ``false``, a function declaration's or function definition's
1659 parameters will either all be on the same line or will have one line each.
1664 void f(int aaaaaaaaaaaaaaaaaaaa, int aaaaaaaaaaaaaaaaaaaa,
1665 int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
1668 void f(int aaaaaaaaaaaaaaaaaaaa,
1669 int aaaaaaaaaaaaaaaaaaaa,
1670 int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
1672 .. _BitFieldColonSpacing:
1674 **BitFieldColonSpacing** (``BitFieldColonSpacingStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BitFieldColonSpacing>`
1675 The BitFieldColonSpacingStyle to use for bitfields.
1679 * ``BFCS_Both`` (in configuration: ``Both``)
1680 Add one space on each side of the ``:``
1686 * ``BFCS_None`` (in configuration: ``None``)
1687 Add no space around the ``:`` (except when needed for
1688 ``AlignConsecutiveBitFields``).
1694 * ``BFCS_Before`` (in configuration: ``Before``)
1695 Add space before the ``:`` only
1701 * ``BFCS_After`` (in configuration: ``After``)
1702 Add space after the ``:`` only (space may be added before if
1703 needed for ``AlignConsecutiveBitFields``).
1713 **BraceWrapping** (``BraceWrappingFlags``) :versionbadge:`clang-format 3.8` :ref:`¶ <BraceWrapping>`
1714 Control of individual brace wrapping cases.
1716 If ``BreakBeforeBraces`` is set to ``BS_Custom``, use this to specify how
1717 each individual brace case should be handled. Otherwise, this is ignored.
1719 .. code-block:: yaml
1722 BreakBeforeBraces: Custom
1726 SplitEmptyFunction: false
1728 Nested configuration flags:
1730 Precise control over the wrapping of braces.
1734 # Should be declared this way:
1735 BreakBeforeBraces: Custom
1739 * ``bool AfterCaseLabel`` Wrap case labels.
1744 switch (foo) { vs. switch (foo) {
1756 * ``bool AfterClass`` Wrap class definitions.
1767 * ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
1768 Wrap control statements (``if``/``for``/``while``/``switch``/..).
1772 * ``BWACS_Never`` (in configuration: ``Never``)
1773 Never wrap braces after a control statement.
1780 for (int i = 0; i < 10; ++i) {
1783 * ``BWACS_MultiLine`` (in configuration: ``MultiLine``)
1784 Only wrap braces after a multi-line control statement.
1793 while (foo || bar) {
1796 * ``BWACS_Always`` (in configuration: ``Always``)
1797 Always wrap braces after a control statement.
1805 for (int i = 0; i < 10; ++i)
1809 * ``bool AfterEnum`` Wrap enum definitions.
1822 * ``bool AfterFunction`` Wrap function definitions.
1839 * ``bool AfterNamespace`` Wrap namespace definitions.
1856 * ``bool AfterObjCDeclaration`` Wrap ObjC definitions (interfaces, implementations...).
1860 @autoreleasepool and @synchronized blocks are wrapped
1861 according to ``AfterControlStatement`` flag.
1863 * ``bool AfterStruct`` Wrap struct definitions.
1878 * ``bool AfterUnion`` Wrap union definitions.
1893 * ``bool AfterExternBlock`` Wrap extern blocks.
1908 * ``bool BeforeCatch`` Wrap before ``catch``.
1925 * ``bool BeforeElse`` Wrap before ``else``.
1940 * ``bool BeforeLambdaBody`` Wrap lambda block.
1958 * ``bool BeforeWhile`` Wrap before ``while``.
1973 * ``bool IndentBraces`` Indent the wrapped braces themselves.
1975 * ``bool SplitEmptyFunction`` If ``false``, empty function body can be put on a single line.
1976 This option is used only if the opening brace of the function has
1977 already been wrapped, i.e. the ``AfterFunction`` brace wrapping mode is
1978 set, and the function could/should not be put on a single line (as per
1979 ``AllowShortFunctionsOnASingleLine`` and constructor formatting
1989 * ``bool SplitEmptyRecord`` If ``false``, empty record (e.g. class, struct or union) body
1990 can be put on a single line. This option is used only if the opening
1991 brace of the record has already been wrapped, i.e. the ``AfterClass``
1992 (for classes) brace wrapping mode is set.
1997 class Foo vs. class Foo
2001 * ``bool SplitEmptyNamespace`` If ``false``, empty namespace body can be put on a single line.
2002 This option is used only if the opening brace of the namespace has
2003 already been wrapped, i.e. the ``AfterNamespace`` brace wrapping mode is
2009 namespace Foo vs. namespace Foo
2014 .. _BracedInitializerIndentWidth:
2016 **BracedInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 17` :ref:`¶ <BracedInitializerIndentWidth>`
2017 The number of columns to use to indent the contents of braced init lists.
2018 If unset, ``ContinuationIndentWidth`` is used.
2022 AlignAfterOpenBracket: AlwaysBreak
2023 BracedInitializerIndentWidth: 2
2031 auto s = SomeStruct{
2049 .. _BreakAdjacentStringLiterals:
2051 **BreakAdjacentStringLiterals** (``Boolean``) :versionbadge:`clang-format 18` :ref:`¶ <BreakAdjacentStringLiterals>`
2052 Break between adjacent string literals.
2062 return "Code" "\0\52\26\55\55\0" "x013" "\02\xBA";
2064 .. _BreakAfterAttributes:
2066 **BreakAfterAttributes** (``AttributeBreakingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakAfterAttributes>`
2067 Break after a group of C++11 attributes before variable or function
2068 (including constructor/destructor) declaration/definition names or before
2069 control statements, i.e. ``if``, ``switch`` (including ``case`` and
2070 ``default`` labels), ``for``, and ``while`` statements.
2074 * ``ABS_Always`` (in configuration: ``Always``)
2075 Always break after attributes.
2081 [[gnu::const]] [[maybe_unused]]
2086 [[gnu::const]] [[nodiscard]]
2105 * ``ABS_Leave`` (in configuration: ``Leave``)
2106 Leave the line breaking after attributes as is.
2110 [[maybe_unused]] const int i;
2111 [[gnu::const]] [[maybe_unused]]
2114 [[nodiscard]] inline int f();
2115 [[gnu::const]] [[nodiscard]]
2124 [[unlikely]] case 1:
2132 * ``ABS_Never`` (in configuration: ``Never``)
2133 Never break after attributes.
2137 [[maybe_unused]] const int i;
2138 [[gnu::const]] [[maybe_unused]] int j;
2140 [[nodiscard]] inline int f();
2141 [[gnu::const]] [[nodiscard]] int g();
2149 [[unlikely]] case 1:
2158 .. _BreakAfterJavaFieldAnnotations:
2160 **BreakAfterJavaFieldAnnotations** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ <BreakAfterJavaFieldAnnotations>`
2161 Break after each annotation on a field in Java files.
2163 .. code-block:: java
2166 @Partial vs. @Partial @Mock DataLoad loader;
2172 **BreakArrays** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <BreakArrays>`
2173 If ``true``, clang-format will always break after a Json array ``[``
2174 otherwise it will scan until the closing ``]`` to determine if it should
2175 add newlines between elements (prettier compatible).
2180 This is currently only for formatting JSON.
2192 .. _BreakBeforeBinaryOperators:
2194 **BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) :versionbadge:`clang-format 3.6` :ref:`¶ <BreakBeforeBinaryOperators>`
2195 The way to wrap binary operators.
2199 * ``BOS_None`` (in configuration: ``None``)
2200 Break after operators.
2204 LooooooooooongType loooooooooooooooooooooongVariable =
2205 someLooooooooooooooooongFunction();
2207 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
2208 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
2209 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
2210 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
2211 ccccccccccccccccccccccccccccccccccccccccc;
2213 * ``BOS_NonAssignment`` (in configuration: ``NonAssignment``)
2214 Break before operators that aren't assignments.
2218 LooooooooooongType loooooooooooooooooooooongVariable =
2219 someLooooooooooooooooongFunction();
2221 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2222 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2223 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2224 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2225 > ccccccccccccccccccccccccccccccccccccccccc;
2227 * ``BOS_All`` (in configuration: ``All``)
2228 Break before operators.
2232 LooooooooooongType loooooooooooooooooooooongVariable
2233 = someLooooooooooooooooongFunction();
2235 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2236 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2237 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2238 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2239 > ccccccccccccccccccccccccccccccccccccccccc;
2243 .. _BreakBeforeBraces:
2245 **BreakBeforeBraces** (``BraceBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeBraces>`
2246 The brace breaking style to use.
2250 * ``BS_Attach`` (in configuration: ``Attach``)
2251 Always attach braces to surrounding context.
2294 void bar() { foo(true); }
2297 * ``BS_Linux`` (in configuration: ``Linux``)
2298 Like ``Attach``, but break before braces on function, namespace and
2346 void bar() { foo(true); }
2349 * ``BS_Mozilla`` (in configuration: ``Mozilla``)
2350 Like ``Attach``, but break before braces on enum, function, and record
2398 void bar() { foo(true); }
2401 * ``BS_Stroustrup`` (in configuration: ``Stroustrup``)
2402 Like ``Attach``, but break before function definitions, ``catch``, and
2450 void bar() { foo(true); }
2453 * ``BS_Allman`` (in configuration: ``Allman``)
2454 Always break before braces.
2512 void bar() { foo(true); }
2515 * ``BS_Whitesmiths`` (in configuration: ``Whitesmiths``)
2516 Like ``Allman`` but always indent braces and line up code with braces.
2574 void bar() { foo(true); }
2577 * ``BS_GNU`` (in configuration: ``GNU``)
2578 Always break before braces and add an extra level of indentation to
2579 braces of control statements, not to those of class, function
2580 or other definitions.
2639 void bar() { foo(true); }
2642 * ``BS_WebKit`` (in configuration: ``WebKit``)
2643 Like ``Attach``, but break before functions.
2688 void bar() { foo(true); }
2691 * ``BS_Custom`` (in configuration: ``Custom``)
2692 Configure each individual brace in ``BraceWrapping``.
2696 .. _BreakBeforeConceptDeclarations:
2698 **BreakBeforeConceptDeclarations** (``BreakBeforeConceptDeclarationsStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BreakBeforeConceptDeclarations>`
2699 The concept declaration style to use.
2703 * ``BBCDS_Never`` (in configuration: ``Never``)
2704 Keep the template declaration line together with ``concept``.
2708 template <typename T> concept C = ...;
2710 * ``BBCDS_Allowed`` (in configuration: ``Allowed``)
2711 Breaking between template declaration and ``concept`` is allowed. The
2712 actual behavior depends on the content and line breaking rules and
2715 * ``BBCDS_Always`` (in configuration: ``Always``)
2716 Always break before ``concept``, putting it in the line after the
2717 template declaration.
2721 template <typename T>
2726 .. _BreakBeforeInlineASMColon:
2728 **BreakBeforeInlineASMColon** (``BreakBeforeInlineASMColonStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakBeforeInlineASMColon>`
2729 The inline ASM colon style to use.
2733 * ``BBIAS_Never`` (in configuration: ``Never``)
2734 No break before inline ASM colon.
2738 asm volatile("string", : : val);
2740 * ``BBIAS_OnlyMultiline`` (in configuration: ``OnlyMultiline``)
2741 Break before inline ASM colon if the line length is longer than column
2746 asm volatile("string", : : val);
2747 asm("cmoveq %1, %2, %[result]"
2748 : [result] "=r"(result)
2749 : "r"(test), "r"(new), "[result]"(old));
2751 * ``BBIAS_Always`` (in configuration: ``Always``)
2752 Always break before inline ASM colon.
2756 asm volatile("string",
2762 .. _BreakBeforeTernaryOperators:
2764 **BreakBeforeTernaryOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeTernaryOperators>`
2765 If ``true``, ternary operators will be placed after line breaks.
2770 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription
2772 : SecondValueVeryVeryVeryVeryLong;
2775 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription ?
2777 SecondValueVeryVeryVeryVeryLong;
2779 .. _BreakConstructorInitializers:
2781 **BreakConstructorInitializers** (``BreakConstructorInitializersStyle``) :versionbadge:`clang-format 5` :ref:`¶ <BreakConstructorInitializers>`
2782 The break constructor initializers style to use.
2786 * ``BCIS_BeforeColon`` (in configuration: ``BeforeColon``)
2787 Break constructor initializers before the colon and after the commas.
2795 * ``BCIS_BeforeComma`` (in configuration: ``BeforeComma``)
2796 Break constructor initializers before the colon and commas, and align
2797 the commas with the colon.
2805 * ``BCIS_AfterColon`` (in configuration: ``AfterColon``)
2806 Break constructor initializers after the colon and commas.
2816 .. _BreakInheritanceList:
2818 **BreakInheritanceList** (``BreakInheritanceListStyle``) :versionbadge:`clang-format 7` :ref:`¶ <BreakInheritanceList>`
2819 The inheritance list style to use.
2823 * ``BILS_BeforeColon`` (in configuration: ``BeforeColon``)
2824 Break inheritance list before the colon and after the commas.
2833 * ``BILS_BeforeComma`` (in configuration: ``BeforeComma``)
2834 Break inheritance list before the colon and commas, and align
2835 the commas with the colon.
2844 * ``BILS_AfterColon`` (in configuration: ``AfterColon``)
2845 Break inheritance list after the colon and commas.
2854 * ``BILS_AfterComma`` (in configuration: ``AfterComma``)
2855 Break inheritance list only after the commas.
2865 .. _BreakStringLiterals:
2867 **BreakStringLiterals** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <BreakStringLiterals>`
2868 Allow breaking string literals when formatting.
2870 In C, C++, and Objective-C:
2875 const char* x = "veryVeryVeryVeryVeryVe"
2876 "ryVeryVeryVeryVeryVery"
2881 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
2888 string x = "veryVeryVeryVeryVeryVe" +
2889 "ryVeryVeryVeryVeryVery" +
2894 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
2896 C# interpolated strings are not broken.
2903 string x = {"veryVeryVeryVeryVeryVe",
2904 "ryVeryVeryVeryVeryVery",
2909 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
2913 **ColumnLimit** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ColumnLimit>`
2916 A column limit of ``0`` means that there is no column limit. In this case,
2917 clang-format will respect the input's line breaking decisions within
2918 statements unless they contradict other rules.
2922 **CommentPragmas** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <CommentPragmas>`
2923 A regular expression that describes comments with special meaning,
2924 which should not be split into lines or otherwise changed.
2928 // CommentPragmas: '^ FOOBAR pragma:'
2929 // Will leave the following line unaffected
2930 #include <vector> // FOOBAR pragma: keep
2932 .. _CompactNamespaces:
2934 **CompactNamespaces** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <CompactNamespaces>`
2935 If ``true``, consecutive namespace declarations will be on the same
2936 line. If ``false``, each namespace is declared on a new line.
2941 namespace Foo { namespace Bar {
2950 If it does not fit on a single line, the overflowing namespaces get
2955 namespace Foo { namespace Bar {
2959 .. _ConstructorInitializerAllOnOneLineOrOnePerLine:
2961 **ConstructorInitializerAllOnOneLineOrOnePerLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerAllOnOneLineOrOnePerLine>`
2962 This option is **deprecated**. See ``CurrentLine`` of
2963 ``PackConstructorInitializers``.
2965 .. _ConstructorInitializerIndentWidth:
2967 **ConstructorInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerIndentWidth>`
2968 The number of characters to use for indentation of constructor
2969 initializer lists as well as inheritance lists.
2971 .. _ContinuationIndentWidth:
2973 **ContinuationIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ContinuationIndentWidth>`
2974 Indent width for line continuations.
2978 ContinuationIndentWidth: 2
2980 int i = // VeryVeryVeryVeryVeryLongComment
2981 longFunction( // Again a long comment
2984 .. _Cpp11BracedListStyle:
2986 **Cpp11BracedListStyle** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <Cpp11BracedListStyle>`
2987 If ``true``, format braced lists as best suited for C++11 braced
2990 Important differences:
2991 - No spaces inside the braced list.
2992 - No line break before the closing brace.
2993 - Indentation with the continuation indent, not with the block indent.
2995 Fundamentally, C++11 braced lists are formatted exactly like function
2996 calls would be formatted in their place. If the braced list follows a name
2997 (e.g. a type or variable name), clang-format formats as if the ``{}`` were
2998 the parentheses of a function call with that name. If there is no name,
2999 a zero-length name is assumed.
3004 vector<int> x{1, 2, 3, 4}; vs. vector<int> x{ 1, 2, 3, 4 };
3005 vector<T> x{{}, {}, {}, {}}; vector<T> x{ {}, {}, {}, {} };
3006 f(MyMap[{composite, key}]); f(MyMap[{ composite, key }]);
3007 new int[3]{1, 2, 3}; new int[3]{ 1, 2, 3 };
3009 .. _DeriveLineEnding:
3011 **DeriveLineEnding** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <DeriveLineEnding>`
3012 This option is **deprecated**. See ``DeriveLF`` and ``DeriveCRLF`` of
3015 .. _DerivePointerAlignment:
3017 **DerivePointerAlignment** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DerivePointerAlignment>`
3018 If ``true``, analyze the formatted file for the most common
3019 alignment of ``&`` and ``*``.
3020 Pointer and reference alignment styles are going to be updated according
3021 to the preferences found in the file.
3022 ``PointerAlignment`` is then used only as fallback.
3026 **DisableFormat** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DisableFormat>`
3027 Disables formatting completely.
3029 .. _EmptyLineAfterAccessModifier:
3031 **EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) :versionbadge:`clang-format 13` :ref:`¶ <EmptyLineAfterAccessModifier>`
3032 Defines when to put an empty line after access modifiers.
3033 ``EmptyLineBeforeAccessModifier`` configuration handles the number of
3034 empty lines between two access modifiers.
3038 * ``ELAAMS_Never`` (in configuration: ``Never``)
3039 Remove all empty lines after access modifiers.
3055 * ``ELAAMS_Leave`` (in configuration: ``Leave``)
3056 Keep existing empty lines after access modifiers.
3057 MaxEmptyLinesToKeep is applied instead.
3059 * ``ELAAMS_Always`` (in configuration: ``Always``)
3060 Always add empty line after access modifiers if there are none.
3061 MaxEmptyLinesToKeep is applied also.
3084 .. _EmptyLineBeforeAccessModifier:
3086 **EmptyLineBeforeAccessModifier** (``EmptyLineBeforeAccessModifierStyle``) :versionbadge:`clang-format 12` :ref:`¶ <EmptyLineBeforeAccessModifier>`
3087 Defines in which cases to put empty line before access modifiers.
3091 * ``ELBAMS_Never`` (in configuration: ``Never``)
3092 Remove all empty lines before access modifiers.
3108 * ``ELBAMS_Leave`` (in configuration: ``Leave``)
3109 Keep existing empty lines before access modifiers.
3111 * ``ELBAMS_LogicalBlock`` (in configuration: ``LogicalBlock``)
3112 Add empty line only when access modifier starts a new logical block.
3113 Logical block is a group of one or more member fields or functions.
3131 * ``ELBAMS_Always`` (in configuration: ``Always``)
3132 Always add empty line before access modifiers unless access modifier
3133 is at the start of struct or class definition.
3155 .. _ExperimentalAutoDetectBinPacking:
3157 **ExperimentalAutoDetectBinPacking** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ExperimentalAutoDetectBinPacking>`
3158 If ``true``, clang-format detects whether function calls and
3159 definitions are formatted with one parameter per line.
3161 Each call can be bin-packed, one-per-line or inconclusive. If it is
3162 inconclusive, e.g. completely on one line, but a decision needs to be
3163 made, clang-format analyzes whether there are other bin-packed cases in
3164 the input file and act accordingly.
3169 This is an experimental flag, that might go away or be renamed. Do
3170 not use this in config files, etc. Use at your own risk.
3172 .. _FixNamespaceComments:
3174 **FixNamespaceComments** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <FixNamespaceComments>`
3175 If ``true``, clang-format adds missing namespace end comments for
3176 namespaces and fixes invalid existing ones. This doesn't affect short
3177 namespaces, which are controlled by ``ShortNamespaceLines``.
3182 namespace longNamespace { vs. namespace longNamespace {
3183 void foo(); void foo();
3184 void bar(); void bar();
3186 namespace shortNamespace { namespace shortNamespace {
3187 void baz(); void baz();
3192 **ForEachMacros** (``List of Strings``) :versionbadge:`clang-format 3.7` :ref:`¶ <ForEachMacros>`
3193 A vector of macros that should be interpreted as foreach loops
3194 instead of as function calls.
3196 These are expected to be macros of the form:
3200 FOREACH(<variable-declaration>, ...)
3203 In the .clang-format configuration file, this can be configured like:
3205 .. code-block:: yaml
3207 ForEachMacros: ['RANGES_FOR', 'FOREACH']
3209 For example: BOOST_FOREACH.
3213 **IfMacros** (``List of Strings``) :versionbadge:`clang-format 13` :ref:`¶ <IfMacros>`
3214 A vector of macros that should be interpreted as conditionals
3215 instead of as function calls.
3217 These are expected to be macros of the form:
3226 In the .clang-format configuration file, this can be configured like:
3228 .. code-block:: yaml
3232 For example: `KJ_IF_MAYBE
3233 <https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes>`_
3237 **IncludeBlocks** (``IncludeBlocksStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IncludeBlocks>`
3238 Dependent on the value, multiple ``#include`` blocks can be sorted
3239 as one and divided based on category.
3243 * ``IBS_Preserve`` (in configuration: ``Preserve``)
3244 Sort each ``#include`` block separately.
3248 #include "b.h" into #include "b.h"
3250 #include <lib/main.h> #include "a.h"
3251 #include "a.h" #include <lib/main.h>
3253 * ``IBS_Merge`` (in configuration: ``Merge``)
3254 Merge multiple ``#include`` blocks together and sort as one.
3258 #include "b.h" into #include "a.h"
3260 #include <lib/main.h> #include <lib/main.h>
3263 * ``IBS_Regroup`` (in configuration: ``Regroup``)
3264 Merge multiple ``#include`` blocks together and sort as one.
3265 Then split into groups based on category priority. See
3266 ``IncludeCategories``.
3270 #include "b.h" into #include "a.h"
3272 #include <lib/main.h>
3273 #include "a.h" #include <lib/main.h>
3277 .. _IncludeCategories:
3279 **IncludeCategories** (``List of IncludeCategories``) :versionbadge:`clang-format 3.8` :ref:`¶ <IncludeCategories>`
3280 Regular expressions denoting the different ``#include`` categories
3281 used for ordering ``#includes``.
3284 <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
3285 regular expressions are supported.
3287 These regular expressions are matched against the filename of an include
3288 (including the <> or "") in order. The value belonging to the first
3289 matching regular expression is assigned and ``#includes`` are sorted first
3290 according to increasing category number and then alphabetically within
3293 If none of the regular expressions match, INT_MAX is assigned as
3294 category. The main header for a source file automatically gets category 0.
3295 so that it is generally kept at the beginning of the ``#includes``
3296 (https://llvm.org/docs/CodingStandards.html#include-style). However, you
3297 can also assign negative priorities if you have certain headers that
3298 always need to be first.
3300 There is a third and optional field ``SortPriority`` which can used while
3301 ``IncludeBlocks = IBS_Regroup`` to define the priority in which
3302 ``#includes`` should be ordered. The value of ``Priority`` defines the
3303 order of ``#include blocks`` and also allows the grouping of ``#includes``
3304 of different priority. ``SortPriority`` is set to the value of
3305 ``Priority`` as default if it is not assigned.
3307 Each regular expression can be marked as case sensitive with the field
3308 ``CaseSensitive``, per default it is not.
3310 To configure this in the .clang-format file, use:
3312 .. code-block:: yaml
3315 - Regex: '^"(llvm|llvm-c|clang|clang-c)/'
3319 - Regex: '^((<|")(gtest|gmock|isl|json)/)'
3321 - Regex: '<[[:alnum:].]+>'
3327 .. _IncludeIsMainRegex:
3329 **IncludeIsMainRegex** (``String``) :versionbadge:`clang-format 3.9` :ref:`¶ <IncludeIsMainRegex>`
3330 Specify a regular expression of suffixes that are allowed in the
3331 file-to-main-include mapping.
3333 When guessing whether a #include is the "main" include (to assign
3334 category 0, see above), use this regex of allowed suffixes to the header
3335 stem. A partial match is done, so that:
3336 - "" means "arbitrary suffix"
3337 - "$" means "no suffix"
3339 For example, if configured to "(_test)?$", then a header a.h would be seen
3340 as the "main" include in both a.cc and a_test.cc.
3342 .. _IncludeIsMainSourceRegex:
3344 **IncludeIsMainSourceRegex** (``String``) :versionbadge:`clang-format 10` :ref:`¶ <IncludeIsMainSourceRegex>`
3345 Specify a regular expression for files being formatted
3346 that are allowed to be considered "main" in the
3347 file-to-main-include mapping.
3349 By default, clang-format considers files as "main" only when they end
3350 with: ``.c``, ``.cc``, ``.cpp``, ``.c++``, ``.cxx``, ``.m`` or ``.mm``
3352 For these files a guessing of "main" include takes place
3353 (to assign category 0, see above). This config option allows for
3354 additional suffixes and extensions for files to be considered as "main".
3356 For example, if this option is configured to ``(Impl\.hpp)$``,
3357 then a file ``ClassImpl.hpp`` is considered "main" (in addition to
3358 ``Class.c``, ``Class.cc``, ``Class.cpp`` and so on) and "main
3359 include file" logic will be executed (with *IncludeIsMainRegex* setting
3360 also being respected in later phase). Without this option set,
3361 ``ClassImpl.hpp`` would not have the main include file put on top
3362 before any other include.
3364 .. _IndentAccessModifiers:
3366 **IndentAccessModifiers** (``Boolean``) :versionbadge:`clang-format 13` :ref:`¶ <IndentAccessModifiers>`
3367 Specify whether access modifiers should have their own indentation level.
3369 When ``false``, access modifiers are indented (or outdented) relative to
3370 the record members, respecting the ``AccessModifierOffset``. Record
3371 members are indented one level below the record.
3372 When ``true``, access modifiers get their own indentation level. As a
3373 consequence, record members are always indented 2 levels below the record,
3374 regardless of the access modifier presence. Value of the
3375 ``AccessModifierOffset`` is ignored.
3380 class C { vs. class C {
3382 void bar(); void bar();
3383 protected: protected:
3389 void foo() { void foo() {
3393 .. _IndentCaseBlocks:
3395 **IndentCaseBlocks** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <IndentCaseBlocks>`
3396 Indent case label blocks one level from the case label.
3398 When ``false``, the block following the case label uses the same
3399 indentation level as for the case label, treating the case label the same
3401 When ``true``, the block gets indented as a scope block.
3406 switch (fool) { vs. switch (fool) {
3418 .. _IndentCaseLabels:
3420 **IndentCaseLabels** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <IndentCaseLabels>`
3421 Indent case labels one level from the switch statement.
3423 When ``false``, use the same indentation level as for the switch
3424 statement. Switch statement body is always indented one level more than
3425 case labels (except the first block following the case label, which
3426 itself indents the code - unless IndentCaseBlocks is enabled).
3431 switch (fool) { vs. switch (fool) {
3439 .. _IndentExternBlock:
3441 **IndentExternBlock** (``IndentExternBlockStyle``) :versionbadge:`clang-format 11` :ref:`¶ <IndentExternBlock>`
3442 IndentExternBlockStyle is the type of indenting of extern blocks.
3446 * ``IEBS_AfterExternBlock`` (in configuration: ``AfterExternBlock``)
3447 Backwards compatible with AfterExternBlock's indenting.
3451 IndentExternBlock: AfterExternBlock
3452 BraceWrapping.AfterExternBlock: true
3461 IndentExternBlock: AfterExternBlock
3462 BraceWrapping.AfterExternBlock: false
3467 * ``IEBS_NoIndent`` (in configuration: ``NoIndent``)
3468 Does not indent extern blocks.
3476 * ``IEBS_Indent`` (in configuration: ``Indent``)
3477 Indents extern blocks.
3487 .. _IndentGotoLabels:
3489 **IndentGotoLabels** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <IndentGotoLabels>`
3492 When ``false``, goto labels are flushed left.
3497 int f() { vs. int f() {
3498 if (foo()) { if (foo()) {
3506 .. _IndentPPDirectives:
3508 **IndentPPDirectives** (``PPDirectiveIndentStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IndentPPDirectives>`
3509 The preprocessor directive indenting style to use.
3513 * ``PPDIS_None`` (in configuration: ``None``)
3514 Does not indent any directives.
3524 * ``PPDIS_AfterHash`` (in configuration: ``AfterHash``)
3525 Indents directives after the hash.
3535 * ``PPDIS_BeforeHash`` (in configuration: ``BeforeHash``)
3536 Indents directives before the hash.
3548 .. _IndentRequiresClause:
3550 **IndentRequiresClause** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <IndentRequiresClause>`
3551 Indent the requires clause in a template. This only applies when
3552 ``RequiresClausePosition`` is ``OwnLine``, or ``WithFollowing``.
3554 In clang-format 12, 13 and 14 it was named ``IndentRequires``.
3559 template <typename It>
3560 requires Iterator<It>
3561 void sort(It begin, It end) {
3566 template <typename It>
3567 requires Iterator<It>
3568 void sort(It begin, It end) {
3574 **IndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWidth>`
3575 The number of columns to use for indentation.
3588 .. _IndentWrappedFunctionNames:
3590 **IndentWrappedFunctionNames** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWrappedFunctionNames>`
3591 Indent if a function definition or declaration is wrapped after the
3597 LoooooooooooooooooooooooooooooooooooooooongReturnType
3598 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
3601 LoooooooooooooooooooooooooooooooooooooooongReturnType
3602 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
3606 **InsertBraces** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <InsertBraces>`
3607 Insert braces after control statements (``if``, ``else``, ``for``, ``do``,
3608 and ``while``) in C++ unless the control statements are inside macro
3609 definitions or the braces would enclose preprocessor directives.
3613 Setting this option to ``true`` could lead to incorrect code formatting
3614 due to clang-format's lack of complete semantic information. As such,
3615 extra care should be taken to review code changes made by this option.
3621 if (isa<FunctionDecl>(D)) vs. if (isa<FunctionDecl>(D)) {
3622 handleFunctionDecl(D); handleFunctionDecl(D);
3623 else if (isa<VarDecl>(D)) } else if (isa<VarDecl>(D)) {
3624 handleVarDecl(D); handleVarDecl(D);
3629 while (i--) vs. while (i--) {
3630 for (auto *A : D.attrs()) for (auto *A : D.attrs()) {
3631 handleAttr(A); handleAttr(A);
3637 while (i); } while (i);
3639 .. _InsertNewlineAtEOF:
3641 **InsertNewlineAtEOF** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <InsertNewlineAtEOF>`
3642 Insert a newline at end of file if missing.
3644 .. _InsertTrailingCommas:
3646 **InsertTrailingCommas** (``TrailingCommaStyle``) :versionbadge:`clang-format 11` :ref:`¶ <InsertTrailingCommas>`
3647 If set to ``TCS_Wrapped`` will insert trailing commas in container
3648 literals (arrays and objects) that wrap across multiple lines.
3649 It is currently only available for JavaScript
3650 and disabled by default ``TCS_None``.
3651 ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
3652 as inserting the comma disables bin-packing.
3658 aaaaaaaaaaaaaaaaaaaaaaaaaa,
3659 aaaaaaaaaaaaaaaaaaaaaaaaaa,
3660 aaaaaaaaaaaaaaaaaaaaaaaaaa,
3666 * ``TCS_None`` (in configuration: ``None``)
3667 Do not insert trailing commas.
3669 * ``TCS_Wrapped`` (in configuration: ``Wrapped``)
3670 Insert trailing commas in container literals that were wrapped over
3671 multiple lines. Note that this is conceptually incompatible with
3672 bin-packing, because the trailing comma is used as an indicator
3673 that a container should be formatted one-per-line (i.e. not bin-packed).
3674 So inserting a trailing comma counteracts bin-packing.
3678 .. _IntegerLiteralSeparator:
3680 **IntegerLiteralSeparator** (``IntegerLiteralSeparatorStyle``) :versionbadge:`clang-format 16` :ref:`¶ <IntegerLiteralSeparator>`
3681 Format integer literal separators (``'`` for C++ and ``_`` for C#, Java,
3684 Nested configuration flags:
3686 Separator format of integer literals of different bases.
3688 If negative, remove separators. If ``0``, leave the literal as is. If
3689 positive, insert separators between digits starting from the rightmost
3692 For example, the config below will leave separators in binary literals
3693 alone, insert separators in decimal literals to separate the digits into
3694 groups of 3, and remove separators in hexadecimal literals.
3698 IntegerLiteralSeparator:
3703 You can also specify a minimum number of digits (``BinaryMinDigits``,
3704 ``DecimalMinDigits``, and ``HexMinDigits``) the integer literal must
3705 have in order for the separators to be inserted.
3707 * ``int8_t Binary`` Format separators in binary literals.
3709 .. code-block:: text
3711 /* -1: */ b = 0b100111101101;
3712 /* 0: */ b = 0b10011'11'0110'1;
3713 /* 3: */ b = 0b100'111'101'101;
3714 /* 4: */ b = 0b1001'1110'1101;
3716 * ``int8_t BinaryMinDigits`` Format separators in binary literals with a minimum number of digits.
3718 .. code-block:: text
3721 // BinaryMinDigits: 7
3725 * ``int8_t Decimal`` Format separators in decimal literals.
3727 .. code-block:: text
3729 /* -1: */ d = 18446744073709550592ull;
3730 /* 0: */ d = 184467'440737'0'95505'92ull;
3731 /* 3: */ d = 18'446'744'073'709'550'592ull;
3733 * ``int8_t DecimalMinDigits`` Format separators in decimal literals with a minimum number of digits.
3735 .. code-block:: text
3738 // DecimalMinDigits: 5
3742 * ``int8_t Hex`` Format separators in hexadecimal literals.
3744 .. code-block:: text
3746 /* -1: */ h = 0xDEADBEEFDEADBEEFuz;
3747 /* 0: */ h = 0xDEAD'BEEF'DE'AD'BEE'Fuz;
3748 /* 2: */ h = 0xDE'AD'BE'EF'DE'AD'BE'EFuz;
3750 * ``int8_t HexMinDigits`` Format separators in hexadecimal literals with a minimum number of
3753 .. code-block:: text
3761 .. _JavaImportGroups:
3763 **JavaImportGroups** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <JavaImportGroups>`
3764 A vector of prefixes ordered by the desired groups for Java imports.
3766 One group's prefix can be a subset of another - the longest prefix is
3767 always matched. Within a group, the imports are ordered lexicographically.
3768 Static imports are grouped separately and follow the same group rules.
3769 By default, static imports are placed before non-static imports,
3770 but this behavior is changed by another option,
3771 ``SortJavaStaticImport``.
3773 In the .clang-format configuration file, this can be configured like
3774 in the following yaml example. This will result in imports being
3775 formatted as in the Java example below.
3777 .. code-block:: yaml
3779 JavaImportGroups: ['com.example', 'com', 'org']
3782 .. code-block:: java
3784 import static com.example.function1;
3786 import static com.test.function2;
3788 import static org.example.function3;
3790 import com.example.ClassA;
3791 import com.example.Test;
3792 import com.example.a.ClassB;
3794 import com.test.ClassC;
3796 import org.example.ClassD;
3798 .. _JavaScriptQuotes:
3800 **JavaScriptQuotes** (``JavaScriptQuoteStyle``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptQuotes>`
3801 The JavaScriptQuoteStyle to use for JavaScript strings.
3805 * ``JSQS_Leave`` (in configuration: ``Leave``)
3806 Leave string quotes as they are.
3813 * ``JSQS_Single`` (in configuration: ``Single``)
3814 Always use single quotes.
3821 * ``JSQS_Double`` (in configuration: ``Double``)
3822 Always use double quotes.
3831 .. _JavaScriptWrapImports:
3833 **JavaScriptWrapImports** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptWrapImports>`
3834 Whether to wrap JavaScript import/export statements.
3840 VeryLongImportsAreAnnoying,
3841 VeryLongImportsAreAnnoying,
3842 VeryLongImportsAreAnnoying,
3843 } from 'some/module.js'
3846 import {VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying,} from "some/module.js"
3848 .. _KeepEmptyLinesAtEOF:
3850 **KeepEmptyLinesAtEOF** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <KeepEmptyLinesAtEOF>`
3851 Keep empty lines (up to ``MaxEmptyLinesToKeep``) at end of file.
3853 .. _KeepEmptyLinesAtTheStartOfBlocks:
3855 **KeepEmptyLinesAtTheStartOfBlocks** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <KeepEmptyLinesAtTheStartOfBlocks>`
3856 If true, the empty line at the start of blocks is kept.
3861 if (foo) { vs. if (foo) {
3866 .. _LambdaBodyIndentation:
3868 **LambdaBodyIndentation** (``LambdaBodyIndentationKind``) :versionbadge:`clang-format 13` :ref:`¶ <LambdaBodyIndentation>`
3869 The indentation style of lambda bodies. ``Signature`` (the default)
3870 causes the lambda body to be indented one additional level relative to
3871 the indentation level of the signature. ``OuterScope`` forces the lambda
3872 body to be indented one additional level relative to the parent scope
3873 containing the lambda signature.
3877 * ``LBI_Signature`` (in configuration: ``Signature``)
3878 Align lambda body relative to the lambda signature. This is the default.
3883 [](SomeReallyLongLambdaSignatureArgument foo) {
3887 * ``LBI_OuterScope`` (in configuration: ``OuterScope``)
3888 For statements within block scope, align lambda body relative to the
3889 indentation level of the outer scope the lambda signature resides in.
3894 [](SomeReallyLongLambdaSignatureArgument foo) {
3898 someMethod(someOtherMethod(
3899 [](SomeReallyLongLambdaSignatureArgument foo) {
3907 **Language** (``LanguageKind``) :versionbadge:`clang-format 3.5` :ref:`¶ <Language>`
3908 Language, this format style is targeted at.
3912 * ``LK_None`` (in configuration: ``None``)
3915 * ``LK_Cpp`` (in configuration: ``Cpp``)
3916 Should be used for C, C++.
3918 * ``LK_CSharp`` (in configuration: ``CSharp``)
3919 Should be used for C#.
3921 * ``LK_Java`` (in configuration: ``Java``)
3922 Should be used for Java.
3924 * ``LK_JavaScript`` (in configuration: ``JavaScript``)
3925 Should be used for JavaScript.
3927 * ``LK_Json`` (in configuration: ``Json``)
3928 Should be used for JSON.
3930 * ``LK_ObjC`` (in configuration: ``ObjC``)
3931 Should be used for Objective-C, Objective-C++.
3933 * ``LK_Proto`` (in configuration: ``Proto``)
3934 Should be used for Protocol Buffers
3935 (https://developers.google.com/protocol-buffers/).
3937 * ``LK_TableGen`` (in configuration: ``TableGen``)
3938 Should be used for TableGen code.
3940 * ``LK_TextProto`` (in configuration: ``TextProto``)
3941 Should be used for Protocol Buffer messages in text format
3942 (https://developers.google.com/protocol-buffers/).
3944 * ``LK_Verilog`` (in configuration: ``Verilog``)
3945 Should be used for Verilog and SystemVerilog.
3946 https://standards.ieee.org/ieee/1800/6700/
3947 https://sci-hub.st/10.1109/IEEESTD.2018.8299595
3953 **LineEnding** (``LineEndingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <LineEnding>`
3954 Line ending style (``\n`` or ``\r\n``) to use.
3958 * ``LE_LF`` (in configuration: ``LF``)
3961 * ``LE_CRLF`` (in configuration: ``CRLF``)
3964 * ``LE_DeriveLF`` (in configuration: ``DeriveLF``)
3965 Use ``\n`` unless the input has more lines ending in ``\r\n``.
3967 * ``LE_DeriveCRLF`` (in configuration: ``DeriveCRLF``)
3968 Use ``\r\n`` unless the input has more lines ending in ``\n``.
3972 .. _MacroBlockBegin:
3974 **MacroBlockBegin** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockBegin>`
3975 A regular expression matching macros that start a block.
3980 MacroBlockBegin: "^NS_MAP_BEGIN|\
4005 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockEnd>`
4006 A regular expression matching macros that end a block.
4010 **Macros** (``List of Strings``) :versionbadge:`clang-format 17` :ref:`¶ <Macros>`
4011 A list of macros of the form ``<definition>=<expansion>`` .
4013 Code will be parsed with macros expanded, in order to determine how to
4014 interpret and format the macro arguments.
4016 For example, the code:
4022 will usually be interpreted as a call to a function A, and the
4023 multiplication expression will be formatted as ``a * b``.
4025 If we specify the macro definition:
4027 .. code-block:: yaml
4032 the code will now be parsed as a declaration of the variable b of type a*,
4033 and formatted as ``a* b`` (depending on pointer-binding rules).
4035 Features and restrictions:
4036 * Both function-like macros and object-like macros are supported.
4037 * Macro arguments must be used exactly once in the expansion.
4038 * No recursive expansion; macros referencing other macros will be
4040 * Overloading by arity is supported: for example, given the macro
4041 definitions A=x, A()=y, A(a)=a
4049 A(a, b); // will not be expanded.
4051 .. _MaxEmptyLinesToKeep:
4053 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <MaxEmptyLinesToKeep>`
4054 The maximum number of consecutive empty lines to keep.
4058 MaxEmptyLinesToKeep: 1 vs. MaxEmptyLinesToKeep: 0
4062 i = foo(); return i;
4067 .. _NamespaceIndentation:
4069 **NamespaceIndentation** (``NamespaceIndentationKind``) :versionbadge:`clang-format 3.7` :ref:`¶ <NamespaceIndentation>`
4070 The indentation used for namespaces.
4074 * ``NI_None`` (in configuration: ``None``)
4075 Don't indent in namespaces.
4086 * ``NI_Inner`` (in configuration: ``Inner``)
4087 Indent only in inner namespaces (nested in other namespaces).
4098 * ``NI_All`` (in configuration: ``All``)
4099 Indent in all namespaces.
4112 .. _NamespaceMacros:
4114 **NamespaceMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <NamespaceMacros>`
4115 A vector of macros which are used to open namespace blocks.
4117 These are expected to be macros of the form:
4121 NAMESPACE(<namespace-name>, ...) {
4125 For example: TESTSUITE
4127 .. _ObjCBinPackProtocolList:
4129 **ObjCBinPackProtocolList** (``BinPackStyle``) :versionbadge:`clang-format 7` :ref:`¶ <ObjCBinPackProtocolList>`
4130 Controls bin-packing Objective-C protocol conformance list
4131 items into as few lines as possible when they go over ``ColumnLimit``.
4133 If ``Auto`` (the default), delegates to the value in
4134 ``BinPackParameters``. If that is ``true``, bin-packs Objective-C
4135 protocol conformance list items into as few lines as possible
4136 whenever they go over ``ColumnLimit``.
4138 If ``Always``, always bin-packs Objective-C protocol conformance
4139 list items into as few lines as possible whenever they go over
4142 If ``Never``, lays out Objective-C protocol conformance list items
4143 onto individual lines whenever they go over ``ColumnLimit``.
4146 .. code-block:: objc
4148 Always (or Auto, if BinPackParameters=true):
4149 @interface ccccccccccccc () <
4150 ccccccccccccc, ccccccccccccc,
4151 ccccccccccccc, ccccccccccccc> {
4154 Never (or Auto, if BinPackParameters=false):
4155 @interface ddddddddddddd () <
4164 * ``BPS_Auto`` (in configuration: ``Auto``)
4165 Automatically determine parameter bin-packing behavior.
4167 * ``BPS_Always`` (in configuration: ``Always``)
4168 Always bin-pack parameters.
4170 * ``BPS_Never`` (in configuration: ``Never``)
4171 Never bin-pack parameters.
4175 .. _ObjCBlockIndentWidth:
4177 **ObjCBlockIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCBlockIndentWidth>`
4178 The number of characters to use for indentation of ObjC blocks.
4180 .. code-block:: objc
4182 ObjCBlockIndentWidth: 4
4184 [operation setCompletionBlock:^{
4185 [self onOperationDone];
4188 .. _ObjCBreakBeforeNestedBlockParam:
4190 **ObjCBreakBeforeNestedBlockParam** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <ObjCBreakBeforeNestedBlockParam>`
4191 Break parameters list into lines when there is nested block
4192 parameters in a function call.
4199 [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
4209 callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
4214 .. _ObjCPropertyAttributeOrder:
4216 **ObjCPropertyAttributeOrder** (``List of Strings``) :versionbadge:`clang-format 18` :ref:`¶ <ObjCPropertyAttributeOrder>`
4217 The order in which ObjC property attributes should appear.
4219 Attributes in code will be sorted in the order specified. Any attributes
4220 encountered that are not mentioned in this array will be sorted last, in
4221 stable order. Comments between attributes will leave the attributes
4226 Using this option could lead to incorrect code formatting due to
4227 clang-format's lack of complete semantic information. As such, extra
4228 care should be taken to review code changes made by this option.
4230 .. code-block:: yaml
4232 ObjCPropertyAttributeOrder: [
4235 assign, retain, strong, copy, weak, unsafe_unretained,
4236 readonly, readwrite, getter, setter,
4237 nullable, nonnull, null_resettable, null_unspecified
4240 .. _ObjCSpaceAfterProperty:
4242 **ObjCSpaceAfterProperty** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceAfterProperty>`
4243 Add a space after ``@property`` in Objective-C, i.e. use
4244 ``@property (readonly)`` instead of ``@property(readonly)``.
4246 .. _ObjCSpaceBeforeProtocolList:
4248 **ObjCSpaceBeforeProtocolList** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceBeforeProtocolList>`
4249 Add a space in front of an Objective-C protocol list, i.e. use
4250 ``Foo <Protocol>`` instead of ``Foo<Protocol>``.
4254 **PPIndentWidth** (``Integer``) :versionbadge:`clang-format 13` :ref:`¶ <PPIndentWidth>`
4255 The number of columns to use for indentation of preprocessor statements.
4256 When set to -1 (default) ``IndentWidth`` is used also for preprocessor
4269 .. _PackConstructorInitializers:
4271 **PackConstructorInitializers** (``PackConstructorInitializersStyle``) :versionbadge:`clang-format 14` :ref:`¶ <PackConstructorInitializers>`
4272 The pack constructor initializers style to use.
4276 * ``PCIS_Never`` (in configuration: ``Never``)
4277 Always put each constructor initializer on its own line.
4285 * ``PCIS_BinPack`` (in configuration: ``BinPack``)
4286 Bin-pack constructor initializers.
4291 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(),
4292 cccccccccccccccccccc()
4294 * ``PCIS_CurrentLine`` (in configuration: ``CurrentLine``)
4295 Put all constructor initializers on the current line if they fit.
4296 Otherwise, put each one on its own line.
4300 Constructor() : a(), b()
4303 : aaaaaaaaaaaaaaaaaaaa(),
4304 bbbbbbbbbbbbbbbbbbbb(),
4307 * ``PCIS_NextLine`` (in configuration: ``NextLine``)
4308 Same as ``PCIS_CurrentLine`` except that if all constructor initializers
4309 do not fit on the current line, try to fit them on the next line.
4313 Constructor() : a(), b()
4316 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), ddddddddddddd()
4319 : aaaaaaaaaaaaaaaaaaaa(),
4320 bbbbbbbbbbbbbbbbbbbb(),
4321 cccccccccccccccccccc()
4323 * ``PCIS_NextLineOnly`` (in configuration: ``NextLineOnly``)
4324 Put all constructor initializers on the next line if they fit.
4325 Otherwise, put each one on its own line.
4333 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), ddddddddddddd()
4336 : aaaaaaaaaaaaaaaaaaaa(),
4337 bbbbbbbbbbbbbbbbbbbb(),
4338 cccccccccccccccccccc()
4342 .. _PenaltyBreakAssignment:
4344 **PenaltyBreakAssignment** (``Unsigned``) :versionbadge:`clang-format 5` :ref:`¶ <PenaltyBreakAssignment>`
4345 The penalty for breaking around an assignment operator.
4347 .. _PenaltyBreakBeforeFirstCallParameter:
4349 **PenaltyBreakBeforeFirstCallParameter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakBeforeFirstCallParameter>`
4350 The penalty for breaking a function call after ``call(``.
4352 .. _PenaltyBreakComment:
4354 **PenaltyBreakComment** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakComment>`
4355 The penalty for each line break introduced inside a comment.
4357 .. _PenaltyBreakFirstLessLess:
4359 **PenaltyBreakFirstLessLess** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakFirstLessLess>`
4360 The penalty for breaking before the first ``<<``.
4362 .. _PenaltyBreakOpenParenthesis:
4364 **PenaltyBreakOpenParenthesis** (``Unsigned``) :versionbadge:`clang-format 14` :ref:`¶ <PenaltyBreakOpenParenthesis>`
4365 The penalty for breaking after ``(``.
4367 .. _PenaltyBreakString:
4369 **PenaltyBreakString** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakString>`
4370 The penalty for each line break introduced inside a string literal.
4372 .. _PenaltyBreakTemplateDeclaration:
4374 **PenaltyBreakTemplateDeclaration** (``Unsigned``) :versionbadge:`clang-format 7` :ref:`¶ <PenaltyBreakTemplateDeclaration>`
4375 The penalty for breaking after template declaration.
4377 .. _PenaltyExcessCharacter:
4379 **PenaltyExcessCharacter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyExcessCharacter>`
4380 The penalty for each character outside of the column limit.
4382 .. _PenaltyIndentedWhitespace:
4384 **PenaltyIndentedWhitespace** (``Unsigned``) :versionbadge:`clang-format 12` :ref:`¶ <PenaltyIndentedWhitespace>`
4385 Penalty for each character of whitespace indentation
4386 (counted relative to leading non-whitespace column).
4388 .. _PenaltyReturnTypeOnItsOwnLine:
4390 **PenaltyReturnTypeOnItsOwnLine** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyReturnTypeOnItsOwnLine>`
4391 Penalty for putting the return type of a function onto its own line.
4393 .. _PointerAlignment:
4395 **PointerAlignment** (``PointerAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <PointerAlignment>`
4396 Pointer and reference alignment style.
4400 * ``PAS_Left`` (in configuration: ``Left``)
4401 Align pointer to the left.
4407 * ``PAS_Right`` (in configuration: ``Right``)
4408 Align pointer to the right.
4414 * ``PAS_Middle`` (in configuration: ``Middle``)
4415 Align pointer in the middle.
4423 .. _QualifierAlignment:
4425 **QualifierAlignment** (``QualifierAlignmentStyle``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierAlignment>`
4426 Different ways to arrange specifiers and qualifiers (e.g. const/volatile).
4430 Setting ``QualifierAlignment`` to something other than ``Leave``, COULD
4431 lead to incorrect code formatting due to incorrect decisions made due to
4432 clang-formats lack of complete semantic information.
4433 As such extra care should be taken to review code changes made by the use
4438 * ``QAS_Leave`` (in configuration: ``Leave``)
4439 Don't change specifiers/qualifiers to either Left or Right alignment
4447 * ``QAS_Left`` (in configuration: ``Left``)
4448 Change specifiers/qualifiers to be left-aligned.
4455 * ``QAS_Right`` (in configuration: ``Right``)
4456 Change specifiers/qualifiers to be right-aligned.
4463 * ``QAS_Custom`` (in configuration: ``Custom``)
4464 Change specifiers/qualifiers to be aligned based on ``QualifierOrder``.
4467 .. code-block:: yaml
4469 QualifierOrder: ['inline', 'static', 'type', 'const']
4482 **QualifierOrder** (``List of Strings``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierOrder>`
4483 The order in which the qualifiers appear.
4484 Order is an array that can contain any of the following:
4498 it MUST contain 'type'.
4500 Items to the left of 'type' will be placed to the left of the type and
4501 aligned in the order supplied. Items to the right of 'type' will be
4502 placed to the right of the type and aligned in the order supplied.
4505 .. code-block:: yaml
4507 QualifierOrder: ['inline', 'static', 'type', 'const', 'volatile' ]
4509 .. _RawStringFormats:
4511 **RawStringFormats** (``List of RawStringFormats``) :versionbadge:`clang-format 6` :ref:`¶ <RawStringFormats>`
4512 Defines hints for detecting supported languages code blocks in raw
4515 A raw string with a matching delimiter or a matching enclosing function
4516 name will be reformatted assuming the specified language based on the
4517 style for that language defined in the .clang-format file. If no style has
4518 been defined in the .clang-format file for the specific language, a
4519 predefined style given by 'BasedOnStyle' is used. If 'BasedOnStyle' is not
4520 found, the formatting is based on llvm style. A matching delimiter takes
4521 precedence over a matching enclosing function name for determining the
4522 language of the raw string contents.
4524 If a canonical delimiter is specified, occurrences of other delimiters for
4525 the same language will be updated to the canonical if possible.
4527 There should be at most one specification per language and each delimiter
4528 and enclosing function should not occur in multiple specifications.
4530 To configure this in the .clang-format file, use:
4532 .. code-block:: yaml
4535 - Language: TextProto
4540 - 'PARSE_TEXT_PROTO'
4541 BasedOnStyle: google
4547 CanonicalDelimiter: 'cc'
4549 .. _ReferenceAlignment:
4551 **ReferenceAlignment** (``ReferenceAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ <ReferenceAlignment>`
4552 Reference alignment style (overrides ``PointerAlignment`` for
4557 * ``RAS_Pointer`` (in configuration: ``Pointer``)
4558 Align reference like ``PointerAlignment``.
4560 * ``RAS_Left`` (in configuration: ``Left``)
4561 Align reference to the left.
4567 * ``RAS_Right`` (in configuration: ``Right``)
4568 Align reference to the right.
4574 * ``RAS_Middle`` (in configuration: ``Middle``)
4575 Align reference in the middle.
4585 **ReflowComments** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ <ReflowComments>`
4586 If ``true``, clang-format will attempt to re-flow comments. That is it
4587 will touch a comment and *reflow* long comments into new lines, trying to
4588 obey the ``ColumnLimit``.
4593 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
4594 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information */
4597 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
4599 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
4602 .. _RemoveBracesLLVM:
4604 **RemoveBracesLLVM** (``Boolean``) :versionbadge:`clang-format 14` :ref:`¶ <RemoveBracesLLVM>`
4605 Remove optional braces of control statements (``if``, ``else``, ``for``,
4606 and ``while``) in C++ according to the LLVM coding style.
4610 This option will be renamed and expanded to support other styles.
4614 Setting this option to ``true`` could lead to incorrect code formatting
4615 due to clang-format's lack of complete semantic information. As such,
4616 extra care should be taken to review code changes made by this option.
4622 if (isa<FunctionDecl>(D)) { vs. if (isa<FunctionDecl>(D))
4623 handleFunctionDecl(D); handleFunctionDecl(D);
4624 } else if (isa<VarDecl>(D)) { else if (isa<VarDecl>(D))
4625 handleVarDecl(D); handleVarDecl(D);
4628 if (isa<VarDecl>(D)) { vs. if (isa<VarDecl>(D)) {
4629 for (auto *A : D.attrs()) { for (auto *A : D.attrs())
4630 if (shouldProcessAttr(A)) { if (shouldProcessAttr(A))
4631 handleAttr(A); handleAttr(A);
4636 if (isa<FunctionDecl>(D)) { vs. if (isa<FunctionDecl>(D))
4637 for (auto *A : D.attrs()) { for (auto *A : D.attrs())
4638 handleAttr(A); handleAttr(A);
4642 if (auto *D = (T)(D)) { vs. if (auto *D = (T)(D)) {
4643 if (shouldProcess(D)) { if (shouldProcess(D))
4644 handleVarDecl(D); handleVarDecl(D);
4646 markAsIgnored(D); markAsIgnored(D);
4652 } else { else if (c)
4660 .. _RemoveParentheses:
4662 **RemoveParentheses** (``RemoveParenthesesStyle``) :versionbadge:`clang-format 17` :ref:`¶ <RemoveParentheses>`
4663 Remove redundant parentheses.
4667 Setting this option to any value other than ``Leave`` could lead to
4668 incorrect code formatting due to clang-format's lack of complete semantic
4669 information. As such, extra care should be taken to review code changes
4670 made by this option.
4674 * ``RPS_Leave`` (in configuration: ``Leave``)
4675 Do not remove parentheses.
4679 class __declspec((dllimport)) X {};
4681 return ((a + b) - ((c + d)));
4683 * ``RPS_MultipleParentheses`` (in configuration: ``MultipleParentheses``)
4684 Replace multiple parentheses with single parentheses.
4688 class __declspec(dllimport) X {};
4690 return ((a + b) - (c + d));
4692 * ``RPS_ReturnStatement`` (in configuration: ``ReturnStatement``)
4693 Also remove parentheses enclosing the expression in a
4694 ``return``/``co_return`` statement.
4698 class __declspec(dllimport) X {};
4700 return (a + b) - (c + d);
4704 .. _RemoveSemicolon:
4706 **RemoveSemicolon** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <RemoveSemicolon>`
4707 Remove semicolons after the closing brace of a non-empty function.
4711 Setting this option to ``true`` could lead to incorrect code formatting
4712 due to clang-format's lack of complete semantic information. As such,
4713 extra care should be taken to review code changes made by this option.
4719 int max(int a, int b) { int max(int a, int b) {
4720 return a > b ? a : b; return a > b ? a : b;
4723 .. _RequiresClausePosition:
4725 **RequiresClausePosition** (``RequiresClausePositionStyle``) :versionbadge:`clang-format 15` :ref:`¶ <RequiresClausePosition>`
4726 The position of the ``requires`` clause.
4730 * ``RCPS_OwnLine`` (in configuration: ``OwnLine``)
4731 Always put the ``requires`` clause on its own line.
4735 template <typename T>
4739 template <typename T>
4743 template <typename T>
4748 * ``RCPS_WithPreceding`` (in configuration: ``WithPreceding``)
4749 Try to put the clause together with the preceding part of a declaration.
4750 For class templates: stick to the template declaration.
4751 For function templates: stick to the template declaration.
4752 For function declaration followed by a requires clause: stick to the
4757 template <typename T> requires C<T>
4760 template <typename T> requires C<T>
4763 template <typename T>
4764 void baz(T t) requires C<T>
4767 * ``RCPS_WithFollowing`` (in configuration: ``WithFollowing``)
4768 Try to put the ``requires`` clause together with the class or function
4773 template <typename T>
4774 requires C<T> struct Foo {...
4776 template <typename T>
4777 requires C<T> void bar(T t) {...
4779 template <typename T>
4783 * ``RCPS_SingleLine`` (in configuration: ``SingleLine``)
4784 Try to put everything in the same line if possible. Otherwise normal
4785 line breaking rules take over.
4790 template <typename T> requires C<T> struct Foo {...
4792 template <typename T> requires C<T> void bar(T t) {...
4794 template <typename T> void bar(T t) requires C<T> {...
4796 // Not fitting, one possible example:
4797 template <typename LongName>
4798 requires C<LongName>
4801 template <typename LongName>
4802 requires C<LongName>
4803 void bar(LongName ln) {
4805 template <typename LongName>
4806 void bar(LongName ln)
4807 requires C<LongName> {
4811 .. _RequiresExpressionIndentation:
4813 **RequiresExpressionIndentation** (``RequiresExpressionIndentationKind``) :versionbadge:`clang-format 16` :ref:`¶ <RequiresExpressionIndentation>`
4814 The indentation used for requires expression bodies.
4818 * ``REI_OuterScope`` (in configuration: ``OuterScope``)
4819 Align requires expression body relative to the indentation level of the
4820 outer scope the requires expression resides in.
4821 This is the default.
4825 template <typename T>
4826 concept C = requires(T t) {
4830 * ``REI_Keyword`` (in configuration: ``Keyword``)
4831 Align requires expression body relative to the ``requires`` keyword.
4835 template <typename T>
4836 concept C = requires(T t) {
4842 .. _SeparateDefinitionBlocks:
4844 **SeparateDefinitionBlocks** (``SeparateDefinitionStyle``) :versionbadge:`clang-format 14` :ref:`¶ <SeparateDefinitionBlocks>`
4845 Specifies the use of empty lines to separate definition blocks, including
4846 classes, structs, enums, and functions.
4851 #include <cstring> #include <cstring>
4853 int a, b, c; struct Foo {
4857 public: namespace Ns {
4858 struct Foobar { class Bar {
4860 int b; struct Foobar {
4868 ITEM1, int method1() {
4871 template<typename T>
4872 int method2(T x) { enum List {
4876 int method3(int par) {
4877 // ... template<typename T>
4878 } int method2(T x) {
4884 int method3(int par) {
4894 * ``SDS_Leave`` (in configuration: ``Leave``)
4895 Leave definition blocks as they are.
4897 * ``SDS_Always`` (in configuration: ``Always``)
4898 Insert an empty line between definition blocks.
4900 * ``SDS_Never`` (in configuration: ``Never``)
4901 Remove any empty line between definition blocks.
4905 .. _ShortNamespaceLines:
4907 **ShortNamespaceLines** (``Unsigned``) :versionbadge:`clang-format 13` :ref:`¶ <ShortNamespaceLines>`
4908 The maximal number of unwrapped lines that a short namespace spans.
4911 This determines the maximum length of short namespaces by counting
4912 unwrapped lines (i.e. containing neither opening nor closing
4913 namespace brace) and makes "FixNamespaceComments" omit adding
4914 end comments for those.
4918 ShortNamespaceLines: 1 vs. ShortNamespaceLines: 0
4919 namespace a { namespace a {
4923 ShortNamespaceLines: 1 vs. ShortNamespaceLines: 0
4924 namespace b { namespace b {
4927 } // namespace b } // namespace b
4931 **SortIncludes** (``SortIncludesOptions``) :versionbadge:`clang-format 3.8` :ref:`¶ <SortIncludes>`
4932 Controls if and how clang-format will sort ``#includes``.
4936 * ``SI_Never`` (in configuration: ``Never``)
4937 Includes are never sorted.
4947 * ``SI_CaseSensitive`` (in configuration: ``CaseSensitive``)
4948 Includes are sorted in an ASCIIbetical or case sensitive fashion.
4958 * ``SI_CaseInsensitive`` (in configuration: ``CaseInsensitive``)
4959 Includes are sorted in an alphabetical or case insensitive fashion.
4971 .. _SortJavaStaticImport:
4973 **SortJavaStaticImport** (``SortJavaStaticImportOptions``) :versionbadge:`clang-format 12` :ref:`¶ <SortJavaStaticImport>`
4974 When sorting Java imports, by default static imports are placed before
4975 non-static imports. If ``JavaStaticImportAfterImport`` is ``After``,
4976 static imports are placed after non-static imports.
4980 * ``SJSIO_Before`` (in configuration: ``Before``)
4981 Static imports are placed before non-static imports.
4983 .. code-block:: java
4985 import static org.example.function1;
4987 import org.example.ClassA;
4989 * ``SJSIO_After`` (in configuration: ``After``)
4990 Static imports are placed after non-static imports.
4992 .. code-block:: java
4994 import org.example.ClassA;
4996 import static org.example.function1;
5000 .. _SortUsingDeclarations:
5002 **SortUsingDeclarations** (``SortUsingDeclarationsOptions``) :versionbadge:`clang-format 5` :ref:`¶ <SortUsingDeclarations>`
5003 Controls if and how clang-format will sort using declarations.
5007 * ``SUD_Never`` (in configuration: ``Never``)
5008 Using declarations are never sorted.
5012 using std::chrono::duration_cast;
5015 using boost::regex_constants::icase;
5018 * ``SUD_Lexicographic`` (in configuration: ``Lexicographic``)
5019 Using declarations are sorted in the order defined as follows:
5020 Split the strings by "::" and discard any initial empty strings. Sort
5021 the lists of names lexicographically, and within those groups, names are
5022 in case-insensitive lexicographic order.
5027 using boost::regex_constants::icase;
5028 using std::chrono::duration_cast;
5032 * ``SUD_LexicographicNumeric`` (in configuration: ``LexicographicNumeric``)
5033 Using declarations are sorted in the order defined as follows:
5034 Split the strings by "::" and discard any initial empty strings. The
5035 last element of each list is a non-namespace name; all others are
5036 namespace names. Sort the lists of names lexicographically, where the
5037 sort order of individual names is that all non-namespace names come
5038 before all namespace names, and within those groups, names are in
5039 case-insensitive lexicographic order.
5044 using boost::regex_constants::icase;
5047 using std::chrono::duration_cast;
5051 .. _SpaceAfterCStyleCast:
5053 **SpaceAfterCStyleCast** (``Boolean``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceAfterCStyleCast>`
5054 If ``true``, a space is inserted after C style casts.
5059 (int) i; vs. (int)i;
5061 .. _SpaceAfterLogicalNot:
5063 **SpaceAfterLogicalNot** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <SpaceAfterLogicalNot>`
5064 If ``true``, a space is inserted after the logical not operator (``!``).
5069 ! someExpression(); vs. !someExpression();
5071 .. _SpaceAfterTemplateKeyword:
5073 **SpaceAfterTemplateKeyword** (``Boolean``) :versionbadge:`clang-format 4` :ref:`¶ <SpaceAfterTemplateKeyword>`
5074 If ``true``, a space will be inserted after the 'template' keyword.
5079 template <int> void foo(); vs. template<int> void foo();
5081 .. _SpaceAroundPointerQualifiers:
5083 **SpaceAroundPointerQualifiers** (``SpaceAroundPointerQualifiersStyle``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceAroundPointerQualifiers>`
5084 Defines in which cases to put a space before or after pointer qualifiers
5088 * ``SAPQ_Default`` (in configuration: ``Default``)
5089 Don't ensure spaces around pointer qualifiers and use PointerAlignment
5094 PointerAlignment: Left PointerAlignment: Right
5095 void* const* x = NULL; vs. void *const *x = NULL;
5097 * ``SAPQ_Before`` (in configuration: ``Before``)
5098 Ensure that there is a space before pointer qualifiers.
5102 PointerAlignment: Left PointerAlignment: Right
5103 void* const* x = NULL; vs. void * const *x = NULL;
5105 * ``SAPQ_After`` (in configuration: ``After``)
5106 Ensure that there is a space after pointer qualifiers.
5110 PointerAlignment: Left PointerAlignment: Right
5111 void* const * x = NULL; vs. void *const *x = NULL;
5113 * ``SAPQ_Both`` (in configuration: ``Both``)
5114 Ensure that there is a space both before and after pointer qualifiers.
5118 PointerAlignment: Left PointerAlignment: Right
5119 void* const * x = NULL; vs. void * const *x = NULL;
5123 .. _SpaceBeforeAssignmentOperators:
5125 **SpaceBeforeAssignmentOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceBeforeAssignmentOperators>`
5126 If ``false``, spaces will be removed before assignment operators.
5131 int a = 5; vs. int a= 5;
5134 .. _SpaceBeforeCaseColon:
5136 **SpaceBeforeCaseColon** (``Boolean``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceBeforeCaseColon>`
5137 If ``false``, spaces will be removed before case colon.
5142 switch (x) { vs. switch (x) {
5143 case 1 : break; case 1: break;
5146 .. _SpaceBeforeCpp11BracedList:
5148 **SpaceBeforeCpp11BracedList** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCpp11BracedList>`
5149 If ``true``, a space will be inserted before a C++11 braced list
5150 used to initialize an object (after the preceding identifier or type).
5155 Foo foo { bar }; vs. Foo foo{ bar };
5157 vector<int> { 1, 2, 3 }; vector<int>{ 1, 2, 3 };
5158 new int[3] { 1, 2, 3 }; new int[3]{ 1, 2, 3 };
5160 .. _SpaceBeforeCtorInitializerColon:
5162 **SpaceBeforeCtorInitializerColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCtorInitializerColon>`
5163 If ``false``, spaces will be removed before constructor initializer
5169 Foo::Foo() : a(a) {} Foo::Foo(): a(a) {}
5171 .. _SpaceBeforeInheritanceColon:
5173 **SpaceBeforeInheritanceColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeInheritanceColon>`
5174 If ``false``, spaces will be removed before inheritance colon.
5179 class Foo : Bar {} vs. class Foo: Bar {}
5181 .. _SpaceBeforeJsonColon:
5183 **SpaceBeforeJsonColon** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <SpaceBeforeJsonColon>`
5184 If ``true``, a space will be added before a JSON colon. For other
5185 languages, e.g. JavaScript, use ``SpacesInContainerLiterals`` instead.
5191 "key" : "value" vs. "key": "value"
5194 .. _SpaceBeforeParens:
5196 **SpaceBeforeParens** (``SpaceBeforeParensStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceBeforeParens>`
5197 Defines in which cases to put a space before opening parentheses.
5201 * ``SBPO_Never`` (in configuration: ``Never``)
5202 Never put a space before opening parentheses.
5212 * ``SBPO_ControlStatements`` (in configuration: ``ControlStatements``)
5213 Put a space before opening parentheses only after control statement
5214 keywords (``for/if/while...``).
5224 * ``SBPO_ControlStatementsExceptControlMacros`` (in configuration: ``ControlStatementsExceptControlMacros``)
5225 Same as ``SBPO_ControlStatements`` except this option doesn't apply to
5226 ForEach and If macros. This is useful in projects where ForEach/If
5227 macros are treated as function calls instead of control statements.
5228 ``SBPO_ControlStatementsExceptForEachMacros`` remains an alias for
5229 backward compatibility.
5239 * ``SBPO_NonEmptyParentheses`` (in configuration: ``NonEmptyParentheses``)
5240 Put a space before opening parentheses only if the parentheses are not
5252 * ``SBPO_Always`` (in configuration: ``Always``)
5253 Always put a space before opening parentheses, except when it's
5254 prohibited by the syntax rules (in function-like macro definitions) or
5255 when determined by other style rules (after unary operators, opening
5266 * ``SBPO_Custom`` (in configuration: ``Custom``)
5267 Configure each individual space before parentheses in
5268 ``SpaceBeforeParensOptions``.
5272 .. _SpaceBeforeParensOptions:
5274 **SpaceBeforeParensOptions** (``SpaceBeforeParensCustom``) :versionbadge:`clang-format 14` :ref:`¶ <SpaceBeforeParensOptions>`
5275 Control of individual space before parentheses.
5277 If ``SpaceBeforeParens`` is set to ``Custom``, use this to specify
5278 how each individual space before parentheses case should be handled.
5279 Otherwise, this is ignored.
5281 .. code-block:: yaml
5284 SpaceBeforeParens: Custom
5285 SpaceBeforeParensOptions:
5286 AfterControlStatements: true
5287 AfterFunctionDefinitionName: true
5289 Nested configuration flags:
5291 Precise control over the spacing before parentheses.
5295 # Should be declared this way:
5296 SpaceBeforeParens: Custom
5297 SpaceBeforeParensOptions:
5298 AfterControlStatements: true
5299 AfterFunctionDefinitionName: true
5301 * ``bool AfterControlStatements`` If ``true``, put space between control statement keywords
5302 (for/if/while...) and opening parentheses.
5307 if (...) {} vs. if(...) {}
5309 * ``bool AfterForeachMacros`` If ``true``, put space between foreach macros and opening parentheses.
5314 FOREACH (...) vs. FOREACH(...)
5315 <loop-body> <loop-body>
5317 * ``bool AfterFunctionDeclarationName`` If ``true``, put a space between function declaration name and opening
5323 void f (); vs. void f();
5325 * ``bool AfterFunctionDefinitionName`` If ``true``, put a space between function definition name and opening
5331 void f () {} vs. void f() {}
5333 * ``bool AfterIfMacros`` If ``true``, put space between if macros and opening parentheses.
5338 IF (...) vs. IF(...)
5339 <conditional-body> <conditional-body>
5341 * ``bool AfterOverloadedOperator`` If ``true``, put a space between operator overloading and opening
5347 void operator++ (int a); vs. void operator++(int a);
5348 object.operator++ (10); object.operator++(10);
5350 * ``AfterPlacementOperatorStyle AfterPlacementOperator`` :versionbadge:`clang-format 18`
5352 Defines in which cases to put a space between ``new/delete`` operators
5353 and opening parentheses.
5357 * ``APO_Never`` (in configuration: ``Never``)
5358 Remove space after ``new/delete`` operators and before ``(``.
5365 * ``APO_Always`` (in configuration: ``Always``)
5366 Always add space after ``new/delete`` operators and before ``(``.
5373 * ``APO_Leave`` (in configuration: ``Leave``)
5374 Leave placement ``new/delete`` expressions as they are.
5377 * ``bool AfterRequiresInClause`` If ``true``, put space between requires keyword in a requires clause and
5378 opening parentheses, if there is one.
5383 template<typename T> vs. template<typename T>
5384 requires (A<T> && B<T>) requires(A<T> && B<T>)
5387 * ``bool AfterRequiresInExpression`` If ``true``, put space between requires keyword in a requires expression
5388 and opening parentheses.
5393 template<typename T> vs. template<typename T>
5394 concept C = requires (T t) { concept C = requires(T t) {
5398 * ``bool BeforeNonEmptyParentheses`` If ``true``, put a space before opening parentheses only if the
5399 parentheses are not empty.
5404 void f (int a); vs. void f();
5408 .. _SpaceBeforeRangeBasedForLoopColon:
5410 **SpaceBeforeRangeBasedForLoopColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeRangeBasedForLoopColon>`
5411 If ``false``, spaces will be removed before range-based for loop
5417 for (auto v : values) {} vs. for(auto v: values) {}
5419 .. _SpaceBeforeSquareBrackets:
5421 **SpaceBeforeSquareBrackets** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceBeforeSquareBrackets>`
5422 If ``true``, spaces will be before ``[``.
5423 Lambdas will not be affected. Only the first ``[`` will get a space added.
5428 int a [5]; vs. int a[5];
5429 int a [5][5]; vs. int a[5][5];
5431 .. _SpaceInEmptyBlock:
5433 **SpaceInEmptyBlock** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceInEmptyBlock>`
5434 If ``true``, spaces will be inserted into ``{}``.
5439 void f() { } vs. void f() {}
5440 while (true) { } while (true) {}
5442 .. _SpaceInEmptyParentheses:
5444 **SpaceInEmptyParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceInEmptyParentheses>`
5445 If ``true``, spaces may be inserted into ``()``.
5446 This option is **deprecated**. See ``InEmptyParentheses`` of
5447 ``SpacesInParensOptions``.
5449 .. _SpacesBeforeTrailingComments:
5451 **SpacesBeforeTrailingComments** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesBeforeTrailingComments>`
5452 The number of spaces before trailing line comments
5453 (``//`` - comments).
5455 This does not affect trailing block comments (``/*`` - comments) as those
5456 commonly have different usage patterns and a number of special cases. In
5457 the case of Verilog, it doesn't affect a comment right after the opening
5458 parenthesis in the port or parameter list in a module header, because it
5459 is probably for the port on the following line instead of the parenthesis
5464 SpacesBeforeTrailingComments: 3
5473 **SpacesInAngles** (``SpacesInAnglesStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ <SpacesInAngles>`
5474 The SpacesInAnglesStyle to use for template argument lists.
5478 * ``SIAS_Never`` (in configuration: ``Never``)
5479 Remove spaces after ``<`` and before ``>``.
5483 static_cast<int>(arg);
5484 std::function<void(int)> fct;
5486 * ``SIAS_Always`` (in configuration: ``Always``)
5487 Add spaces after ``<`` and before ``>``.
5491 static_cast< int >(arg);
5492 std::function< void(int) > fct;
5494 * ``SIAS_Leave`` (in configuration: ``Leave``)
5495 Keep a single space after ``<`` and before ``>`` if any spaces were
5496 present. Option ``Standard: Cpp03`` takes precedence.
5500 .. _SpacesInCStyleCastParentheses:
5502 **SpacesInCStyleCastParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInCStyleCastParentheses>`
5503 If ``true``, spaces may be inserted into C style casts.
5504 This option is **deprecated**. See ``InCStyleCasts`` of
5505 ``SpacesInParensOptions``.
5507 .. _SpacesInConditionalStatement:
5509 **SpacesInConditionalStatement** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpacesInConditionalStatement>`
5510 If ``true``, spaces will be inserted around if/for/switch/while
5512 This option is **deprecated**. See ``InConditionalStatements`` of
5513 ``SpacesInParensOptions``.
5515 .. _SpacesInContainerLiterals:
5517 **SpacesInContainerLiterals** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInContainerLiterals>`
5518 If ``true``, spaces are inserted inside container literals (e.g. ObjC and
5519 Javascript array and dict literals). For JSON, use
5520 ``SpaceBeforeJsonColon`` instead.
5525 var arr = [ 1, 2, 3 ]; vs. var arr = [1, 2, 3];
5526 f({a : 1, b : 2, c : 3}); f({a: 1, b: 2, c: 3});
5528 .. _SpacesInLineCommentPrefix:
5530 **SpacesInLineCommentPrefix** (``SpacesInLineComment``) :versionbadge:`clang-format 13` :ref:`¶ <SpacesInLineCommentPrefix>`
5531 How many spaces are allowed at the start of a line comment. To disable the
5532 maximum set it to ``-1``, apart from that the maximum takes precedence
5539 // One space is forced
5541 // but more spaces are possible
5545 //Forces to start every comment directly after the slashes
5547 Note that in line comment sections the relative indent of the subsequent
5548 lines is kept, that means the following:
5554 //if (b) { // if (b) {
5555 // return true; // return true;
5563 This option has only effect if ``ReflowComments`` is set to ``true``.
5565 Nested configuration flags:
5567 Control of spaces within a single line comment.
5569 * ``unsigned Minimum`` The minimum number of spaces at the start of the comment.
5571 * ``unsigned Maximum`` The maximum number of spaces at the start of the comment.
5576 **SpacesInParens** (``SpacesInParensStyle``) :versionbadge:`clang-format 17` :ref:`¶ <SpacesInParens>`
5577 Defines in which cases spaces will be inserted after ``(`` and before
5582 * ``SIPO_Never`` (in configuration: ``Never``)
5583 Never put a space in parentheses.
5593 * ``SIPO_Custom`` (in configuration: ``Custom``)
5594 Configure each individual space in parentheses in
5595 `SpacesInParensOptions`.
5599 .. _SpacesInParensOptions:
5601 **SpacesInParensOptions** (``SpacesInParensCustom``) :versionbadge:`clang-format 17` :ref:`¶ <SpacesInParensOptions>`
5602 Control of individual spaces in parentheses.
5604 If ``SpacesInParens`` is set to ``Custom``, use this to specify
5605 how each individual space in parentheses case should be handled.
5606 Otherwise, this is ignored.
5608 .. code-block:: yaml
5611 SpacesInParens: Custom
5612 SpacesInParensOptions:
5613 InConditionalStatements: true
5614 InEmptyParentheses: true
5616 Nested configuration flags:
5618 Precise control over the spacing in parentheses.
5622 # Should be declared this way:
5623 SpacesInParens: Custom
5624 SpacesInParensOptions:
5625 InConditionalStatements: true
5628 * ``bool InConditionalStatements`` Put a space in parentheses only inside conditional statements
5629 (``for/if/while/switch...``).
5634 if ( a ) { ... } vs. if (a) { ... }
5635 while ( i < 5 ) { ... } while (i < 5) { ... }
5637 * ``bool InCStyleCasts`` Put a space in C style casts.
5642 x = ( int32 )y vs. x = (int32)y
5644 * ``bool InEmptyParentheses`` Put a space in parentheses only if the parentheses are empty i.e. '()'
5649 void f( ) { vs. void f() {
5650 int x[] = {foo( ), bar( )}; int x[] = {foo(), bar()};
5651 if (true) { if (true) {
5656 * ``bool Other`` Put a space in parentheses not covered by preceding options.
5661 t f( Deleted & ) & = delete; vs. t f(Deleted &) & = delete;
5664 .. _SpacesInParentheses:
5666 **SpacesInParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInParentheses>`
5667 If ``true``, spaces will be inserted after ``(`` and before ``)``.
5668 This option is **deprecated**. The previous behavior is preserved by using
5669 ``SpacesInParens`` with ``Custom`` and by setting all
5670 ``SpacesInParensOptions`` to ``true`` except for ``InCStyleCasts`` and
5671 ``InEmptyParentheses``.
5673 .. _SpacesInSquareBrackets:
5675 **SpacesInSquareBrackets** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInSquareBrackets>`
5676 If ``true``, spaces will be inserted after ``[`` and before ``]``.
5677 Lambdas without arguments or unspecified size array declarations will not
5683 int a[ 5 ]; vs. int a[5];
5684 std::unique_ptr<int[]> foo() {} // Won't be affected
5688 **Standard** (``LanguageStandard``) :versionbadge:`clang-format 3.7` :ref:`¶ <Standard>`
5689 Parse and format C++ constructs compatible with this standard.
5694 vector<set<int> > x; vs. vector<set<int>> x;
5698 * ``LS_Cpp03`` (in configuration: ``c++03``)
5699 Parse and format as C++03.
5700 ``Cpp03`` is a deprecated alias for ``c++03``
5702 * ``LS_Cpp11`` (in configuration: ``c++11``)
5703 Parse and format as C++11.
5705 * ``LS_Cpp14`` (in configuration: ``c++14``)
5706 Parse and format as C++14.
5708 * ``LS_Cpp17`` (in configuration: ``c++17``)
5709 Parse and format as C++17.
5711 * ``LS_Cpp20`` (in configuration: ``c++20``)
5712 Parse and format as C++20.
5714 * ``LS_Latest`` (in configuration: ``Latest``)
5715 Parse and format using the latest supported language version.
5716 ``Cpp11`` is a deprecated alias for ``Latest``
5718 * ``LS_Auto`` (in configuration: ``Auto``)
5719 Automatic detection based on the input.
5723 .. _StatementAttributeLikeMacros:
5725 **StatementAttributeLikeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <StatementAttributeLikeMacros>`
5726 Macros which are ignored in front of a statement, as if they were an
5727 attribute. So that they are not parsed as identifier, for example for Qts
5732 AlignConsecutiveDeclarations: true
5733 StatementAttributeLikeMacros: []
5734 unsigned char data = 'x';
5735 emit signal(data); // This is parsed as variable declaration.
5737 AlignConsecutiveDeclarations: true
5738 StatementAttributeLikeMacros: [emit]
5739 unsigned char data = 'x';
5740 emit signal(data); // Now it's fine again.
5742 .. _StatementMacros:
5744 **StatementMacros** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <StatementMacros>`
5745 A vector of macros that should be interpreted as complete
5748 Typical macros are expressions, and require a semi-colon to be
5749 added; sometimes this is not the case, and this allows to make
5750 clang-format aware of such cases.
5752 For example: Q_UNUSED
5756 **TabWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <TabWidth>`
5757 The number of columns used for tab stops.
5761 **TypeNames** (``List of Strings``) :versionbadge:`clang-format 17` :ref:`¶ <TypeNames>`
5762 A vector of non-keyword identifiers that should be interpreted as type
5765 A ``*``, ``&``, or ``&&`` between a type name and another non-keyword
5766 identifier is annotated as a pointer or reference token instead of a
5771 **TypenameMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <TypenameMacros>`
5772 A vector of macros that should be interpreted as type declarations
5773 instead of as function calls.
5775 These are expected to be macros of the form:
5781 In the .clang-format configuration file, this can be configured like:
5783 .. code-block:: yaml
5785 TypenameMacros: ['STACK_OF', 'LIST']
5787 For example: OpenSSL STACK_OF, BSD LIST_ENTRY.
5791 **UseCRLF** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <UseCRLF>`
5792 This option is **deprecated**. See ``LF`` and ``CRLF`` of ``LineEnding``.
5796 **UseTab** (``UseTabStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <UseTab>`
5797 The way to use tab characters in the resulting file.
5801 * ``UT_Never`` (in configuration: ``Never``)
5804 * ``UT_ForIndentation`` (in configuration: ``ForIndentation``)
5805 Use tabs only for indentation.
5807 * ``UT_ForContinuationAndIndentation`` (in configuration: ``ForContinuationAndIndentation``)
5808 Fill all leading whitespace with tabs, and use spaces for alignment that
5809 appears within a line (e.g. consecutive assignments and declarations).
5811 * ``UT_AlignWithSpaces`` (in configuration: ``AlignWithSpaces``)
5812 Use tabs for line continuation and indentation, and spaces for
5815 * ``UT_Always`` (in configuration: ``Always``)
5816 Use tabs whenever we need to fill whitespace that spans at least from
5817 one tab stop to the next one.
5821 .. _VerilogBreakBetweenInstancePorts:
5823 **VerilogBreakBetweenInstancePorts** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <VerilogBreakBetweenInstancePorts>`
5824 For Verilog, put each port on its own line in module instantiations.
5835 ffnand ff1(.q(), .qbar(out1), .clear(in1), .preset(in2));
5837 .. _WhitespaceSensitiveMacros:
5839 **WhitespaceSensitiveMacros** (``List of Strings``) :versionbadge:`clang-format 11` :ref:`¶ <WhitespaceSensitiveMacros>`
5840 A vector of macros which are whitespace-sensitive and should not
5843 These are expected to be macros of the form:
5849 In the .clang-format configuration file, this can be configured like:
5851 .. code-block:: yaml
5853 WhitespaceSensitiveMacros: ['STRINGIZE', 'PP_STRINGIZE']
5855 For example: BOOST_PP_STRINGIZE
5857 .. END_FORMAT_STYLE_OPTIONS
5859 Adding additional style options
5860 ===============================
5862 Each additional style option adds costs to the clang-format project. Some of
5863 these costs affect the clang-format development itself, as we need to make
5864 sure that any given combination of options work and that new features don't
5865 break any of the existing options in any way. There are also costs for end users
5866 as options become less discoverable and people have to think about and make a
5867 decision on options they don't really care about.
5869 The goal of the clang-format project is more on the side of supporting a
5870 limited set of styles really well as opposed to supporting every single style
5871 used by a codebase somewhere in the wild. Of course, we do want to support all
5872 major projects and thus have established the following bar for adding style
5873 options. Each new style option must ..
5875 * be used in a project of significant size (have dozens of contributors)
5876 * have a publicly accessible style guide
5877 * have a person willing to contribute and maintain patches
5882 A style similar to the `Linux Kernel style
5883 <https://www.kernel.org/doc/html/latest/process/coding-style.html>`_:
5885 .. code-block:: yaml
5890 BreakBeforeBraces: Linux
5891 AllowShortIfStatementsOnASingleLine: false
5892 IndentCaseLabels: false
5894 The result is (imagine that tabs are used for indentation here):
5906 do_something_else();
5912 do_something_completely_different();
5923 A style similar to the default Visual Studio formatting style:
5925 .. code-block:: yaml
5929 BreakBeforeBraces: Allman
5930 AllowShortIfStatementsOnASingleLine: false
5931 IndentCaseLabels: false
5947 do_something_else();
5953 do_something_completely_different();