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 AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
412 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
413 operators are left-padded to the same length as long ones in order to
414 put all assignment operators to the right of the left hand side.
433 .. _AlignConsecutiveBitFields:
435 **AlignConsecutiveBitFields** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 11` :ref:`¶ <AlignConsecutiveBitFields>`
436 Style of aligning consecutive bit fields.
438 ``Consecutive`` will align the bitfield separators of consecutive lines.
439 This will result in formattings like:
447 Nested configuration flags:
451 They can also be read as a whole for compatibility. The choices are:
456 - AcrossEmptyLinesAndComments
458 For example, to align across empty lines and not across comments, either
463 AlignConsecutiveMacros: AcrossEmptyLines
465 AlignConsecutiveMacros:
467 AcrossEmptyLines: true
468 AcrossComments: false
470 * ``bool Enabled`` Whether aligning is enabled.
474 #define SHORT_NAME 42
475 #define LONGER_NAME 0x007f
476 #define EVEN_LONGER_NAME (2)
477 #define foo(x) (x * x)
478 #define bar(y, z) (y + z)
481 int somelongname = 2;
492 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
498 int somelongname = 2;
505 int somelongname = 2;
510 * ``bool AcrossComments`` Whether to align across comments.
524 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
525 like ``+=`` are aligned along with ``=``.
537 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
554 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
555 operators are left-padded to the same length as long ones in order to
556 put all assignment operators to the right of the left hand side.
575 .. _AlignConsecutiveDeclarations:
577 **AlignConsecutiveDeclarations** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlignConsecutiveDeclarations>`
578 Style of aligning consecutive declarations.
580 ``Consecutive`` will align the declaration names of consecutive lines.
581 This will result in formattings like:
589 Nested configuration flags:
593 They can also be read as a whole for compatibility. The choices are:
598 - AcrossEmptyLinesAndComments
600 For example, to align across empty lines and not across comments, either
605 AlignConsecutiveMacros: AcrossEmptyLines
607 AlignConsecutiveMacros:
609 AcrossEmptyLines: true
610 AcrossComments: false
612 * ``bool Enabled`` Whether aligning is enabled.
616 #define SHORT_NAME 42
617 #define LONGER_NAME 0x007f
618 #define EVEN_LONGER_NAME (2)
619 #define foo(x) (x * x)
620 #define bar(y, z) (y + z)
623 int somelongname = 2;
634 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
640 int somelongname = 2;
647 int somelongname = 2;
652 * ``bool AcrossComments`` Whether to align across comments.
666 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
667 like ``+=`` are aligned along with ``=``.
679 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
696 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
697 operators are left-padded to the same length as long ones in order to
698 put all assignment operators to the right of the left hand side.
717 .. _AlignConsecutiveMacros:
719 **AlignConsecutiveMacros** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AlignConsecutiveMacros>`
720 Style of aligning consecutive macro definitions.
722 ``Consecutive`` will result in formattings like:
726 #define SHORT_NAME 42
727 #define LONGER_NAME 0x007f
728 #define EVEN_LONGER_NAME (2)
729 #define foo(x) (x * x)
730 #define bar(y, z) (y + z)
732 Nested configuration flags:
736 They can also be read as a whole for compatibility. The choices are:
741 - AcrossEmptyLinesAndComments
743 For example, to align across empty lines and not across comments, either
748 AlignConsecutiveMacros: AcrossEmptyLines
750 AlignConsecutiveMacros:
752 AcrossEmptyLines: true
753 AcrossComments: false
755 * ``bool Enabled`` Whether aligning is enabled.
759 #define SHORT_NAME 42
760 #define LONGER_NAME 0x007f
761 #define EVEN_LONGER_NAME (2)
762 #define foo(x) (x * x)
763 #define bar(y, z) (y + z)
766 int somelongname = 2;
777 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
783 int somelongname = 2;
790 int somelongname = 2;
795 * ``bool AcrossComments`` Whether to align across comments.
809 * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``. Whether compound assignments
810 like ``+=`` are aligned along with ``=``.
822 * ``bool AlignFunctionPointers`` Only for ``AlignConsecutiveDeclarations``. Whether function pointers are
839 * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``. Whether short assignment
840 operators are left-padded to the same length as long ones in order to
841 put all assignment operators to the right of the left hand side.
860 .. _AlignConsecutiveShortCaseStatements:
862 **AlignConsecutiveShortCaseStatements** (``ShortCaseStatementsAlignmentStyle``) :versionbadge:`clang-format 17` :ref:`¶ <AlignConsecutiveShortCaseStatements>`
863 Style of aligning consecutive short case labels.
864 Only applies if ``AllowShortCaseLabelsOnASingleLine`` is ``true``.
870 AlignConsecutiveShortCaseStatements:
872 AcrossEmptyLines: true
874 AlignCaseColons: false
876 Nested configuration flags:
880 * ``bool Enabled`` Whether aligning is enabled.
886 case log::info: return "info:";
887 case log::warning: return "warning:";
893 case log::info: return "info:";
894 case log::warning: return "warning:";
898 * ``bool AcrossEmptyLines`` Whether to align across empty lines.
904 case log::info: return "info:";
905 case log::warning: return "warning:";
912 case log::info: return "info:";
913 case log::warning: return "warning:";
918 * ``bool AcrossComments`` Whether to align across comments.
924 case log::info: return "info:";
925 case log::warning: return "warning:";
932 case log::info: return "info:";
933 case log::warning: return "warning:";
938 * ``bool AlignCaseColons`` Whether aligned case labels are aligned on the colon, or on the
939 , or on the tokens after the colon.
945 case log::info : return "info:";
946 case log::warning: return "warning:";
952 case log::info: return "info:";
953 case log::warning: return "warning:";
958 .. _AlignEscapedNewlines:
960 **AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) :versionbadge:`clang-format 5` :ref:`¶ <AlignEscapedNewlines>`
961 Options for aligning backslashes in escaped newlines.
965 * ``ENAS_DontAlign`` (in configuration: ``DontAlign``)
966 Don't align escaped newlines.
975 * ``ENAS_Left`` (in configuration: ``Left``)
976 Align escaped newlines as far left as possible.
988 * ``ENAS_Right`` (in configuration: ``Right``)
989 Align escaped newlines in the right-most column.
1002 **AlignOperands** (``OperandAlignmentStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AlignOperands>`
1003 If ``true``, horizontally align operands of binary and ternary
1008 * ``OAS_DontAlign`` (in configuration: ``DontAlign``)
1009 Do not align operands of binary and ternary expressions.
1010 The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
1011 the start of the line.
1013 * ``OAS_Align`` (in configuration: ``Align``)
1014 Horizontally align operands of binary and ternary expressions.
1016 Specifically, this aligns operands of a single expression that needs
1017 to be split over multiple lines, e.g.:
1021 int aaa = bbbbbbbbbbbbbbb +
1024 When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
1025 aligned with the operand on the first line.
1029 int aaa = bbbbbbbbbbbbbbb
1032 * ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
1033 Horizontally align operands of binary and ternary expressions.
1035 This is similar to ``AO_Align``, except when
1036 ``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
1037 that the wrapped operand is aligned with the operand on the first line.
1041 int aaa = bbbbbbbbbbbbbbb
1046 .. _AlignTrailingComments:
1048 **AlignTrailingComments** (``TrailingCommentsAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlignTrailingComments>`
1049 Control of trailing comments.
1051 The alignment stops at closing braces after a line break, and only
1052 followed by other closing braces, a (``do-``) ``while``, a lambda call, or
1058 As of clang-format 16 this option is not a bool but can be set
1059 to the options. Conventional bool options still can be parsed as before.
1062 .. code-block:: yaml
1065 AlignTrailingComments:
1069 Nested configuration flags:
1073 * ``TrailingCommentsAlignmentKinds Kind``
1074 Specifies the way to align trailing comments.
1078 * ``TCAS_Leave`` (in configuration: ``Leave``)
1079 Leave trailing comments as they are.
1087 int abcd; // comment
1089 * ``TCAS_Always`` (in configuration: ``Always``)
1090 Align trailing comments.
1098 int abcd; // comment
1100 * ``TCAS_Never`` (in configuration: ``Never``)
1101 Don't align trailing comments but other formatter applies.
1109 int abcd; // comment
1112 * ``unsigned OverEmptyLines`` How many empty lines to apply alignment.
1113 When both ``MaxEmptyLinesToKeep`` and ``OverEmptyLines`` are set to 2,
1114 it formats like below.
1120 int ab; // comments are
1123 int abcdef; // aligned
1125 When ``MaxEmptyLinesToKeep`` is set to 2 and ``OverEmptyLines`` is set
1126 to 1, it formats like below.
1135 int abcdef; // but this isn't
1138 .. _AllowAllArgumentsOnNextLine:
1140 **AllowAllArgumentsOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllArgumentsOnNextLine>`
1141 If a function call or braced initializer list doesn't fit on a
1142 line, allow putting all arguments onto the next line, even if
1143 ``BinPackArguments`` is ``false``.
1157 .. _AllowAllConstructorInitializersOnNextLine:
1159 **AllowAllConstructorInitializersOnNextLine** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <AllowAllConstructorInitializersOnNextLine>`
1160 This option is **deprecated**. See ``NextLine`` of
1161 ``PackConstructorInitializers``.
1163 .. _AllowAllParametersOfDeclarationOnNextLine:
1165 **AllowAllParametersOfDeclarationOnNextLine** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowAllParametersOfDeclarationOnNextLine>`
1166 If the function declaration doesn't fit on a line,
1167 allow putting all parameters of a function declaration onto
1168 the next line even if ``BinPackParameters`` is ``false``.
1174 int a, int b, int c, int d, int e);
1177 void myFunction(int a,
1183 .. _AllowBreakBeforeNoexceptSpecifier:
1185 **AllowBreakBeforeNoexceptSpecifier** (``BreakBeforeNoexceptSpecifierStyle``) :versionbadge:`clang-format 18` :ref:`¶ <AllowBreakBeforeNoexceptSpecifier>`
1186 Controls if there could be a line break before a ``noexcept`` specifier.
1190 * ``BBNSS_Never`` (in configuration: ``Never``)
1191 No line break allowed.
1196 double arg2) noexcept;
1198 void bar(int arg1, double arg2) noexcept(
1199 noexcept(baz(arg1)) &&
1200 noexcept(baz(arg2)));
1202 * ``BBNSS_OnlyWithParen`` (in configuration: ``OnlyWithParen``)
1203 For a simple ``noexcept`` there is no line break allowed, but when we
1204 have a condition it is.
1209 double arg2) noexcept;
1211 void bar(int arg1, double arg2)
1212 noexcept(noexcept(baz(arg1)) &&
1213 noexcept(baz(arg2)));
1215 * ``BBNSS_Always`` (in configuration: ``Always``)
1216 Line breaks are allowed. But note that because of the associated
1217 penalties ``clang-format`` often prefers not to break before the
1223 double arg2) noexcept;
1225 void bar(int arg1, double arg2)
1226 noexcept(noexcept(baz(arg1)) &&
1227 noexcept(baz(arg2)));
1231 .. _AllowShortBlocksOnASingleLine:
1233 **AllowShortBlocksOnASingleLine** (``ShortBlockStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortBlocksOnASingleLine>`
1234 Dependent on the value, ``while (true) { continue; }`` can be put on a
1239 * ``SBS_Never`` (in configuration: ``Never``)
1240 Never merge blocks into a single line.
1250 * ``SBS_Empty`` (in configuration: ``Empty``)
1251 Only merge empty blocks.
1260 * ``SBS_Always`` (in configuration: ``Always``)
1261 Always merge short blocks into a single line.
1266 while (true) { continue; }
1270 .. _AllowShortCaseLabelsOnASingleLine:
1272 **AllowShortCaseLabelsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.6` :ref:`¶ <AllowShortCaseLabelsOnASingleLine>`
1273 If ``true``, short case labels will be contracted to a single line.
1278 switch (a) { vs. switch (a) {
1279 case 1: x = 1; break; case 1:
1280 case 2: return; x = 1;
1286 .. _AllowShortCompoundRequirementOnASingleLine:
1288 **AllowShortCompoundRequirementOnASingleLine** (``Boolean``) :versionbadge:`clang-format 18` :ref:`¶ <AllowShortCompoundRequirementOnASingleLine>`
1289 Allow short compound requirement on a single line.
1294 template <typename T>
1295 concept c = requires(T x) {
1296 { x + 1 } -> std::same_as<int>;
1300 template <typename T>
1301 concept c = requires(T x) {
1304 } -> std::same_as<int>;
1307 .. _AllowShortEnumsOnASingleLine:
1309 **AllowShortEnumsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <AllowShortEnumsOnASingleLine>`
1310 Allow short enums on a single line.
1315 enum { A, B } myEnum;
1323 .. _AllowShortFunctionsOnASingleLine:
1325 **AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <AllowShortFunctionsOnASingleLine>`
1326 Dependent on the value, ``int f() { return 0; }`` can be put on a
1331 * ``SFS_None`` (in configuration: ``None``)
1332 Never merge functions into a single line.
1334 * ``SFS_InlineOnly`` (in configuration: ``InlineOnly``)
1335 Only merge functions defined inside a class. Same as "inline",
1336 except it does not implies "empty": i.e. top level empty functions
1337 are not merged either.
1350 * ``SFS_Empty`` (in configuration: ``Empty``)
1351 Only merge empty functions.
1360 * ``SFS_Inline`` (in configuration: ``Inline``)
1361 Only merge functions defined inside a class. Implies "empty".
1373 * ``SFS_All`` (in configuration: ``All``)
1374 Merge all functions fitting on a single line.
1385 .. _AllowShortIfStatementsOnASingleLine:
1387 **AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 3.3` :ref:`¶ <AllowShortIfStatementsOnASingleLine>`
1388 Dependent on the value, ``if (a) return;`` can be put on a single line.
1392 * ``SIS_Never`` (in configuration: ``Never``)
1393 Never put short ifs on the same line.
1411 * ``SIS_WithoutElse`` (in configuration: ``WithoutElse``)
1412 Put short ifs on the same line only if there is no else statement.
1429 * ``SIS_OnlyFirstIf`` (in configuration: ``OnlyFirstIf``)
1430 Put short ifs, but not else ifs nor else statements, on the same line.
1447 * ``SIS_AllIfsAndElse`` (in configuration: ``AllIfsAndElse``)
1448 Always put short ifs, else ifs and else statements on the same
1465 .. _AllowShortLambdasOnASingleLine:
1467 **AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``) :versionbadge:`clang-format 9` :ref:`¶ <AllowShortLambdasOnASingleLine>`
1468 Dependent on the value, ``auto lambda []() { return 0; }`` can be put on a
1473 * ``SLS_None`` (in configuration: ``None``)
1474 Never merge lambdas into a single line.
1476 * ``SLS_Empty`` (in configuration: ``Empty``)
1477 Only merge empty lambdas.
1481 auto lambda = [](int a) {};
1482 auto lambda2 = [](int a) {
1486 * ``SLS_Inline`` (in configuration: ``Inline``)
1487 Merge lambda into a single line if the lambda is argument of a function.
1491 auto lambda = [](int x, int y) {
1494 sort(a.begin(), a.end(), [](int x, int y) { return x < y; });
1496 * ``SLS_All`` (in configuration: ``All``)
1497 Merge all lambdas fitting on a single line.
1501 auto lambda = [](int a) {};
1502 auto lambda2 = [](int a) { return a; };
1506 .. _AllowShortLoopsOnASingleLine:
1508 **AllowShortLoopsOnASingleLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <AllowShortLoopsOnASingleLine>`
1509 If ``true``, ``while (true) continue;`` can be put on a single
1512 .. _AlwaysBreakAfterDefinitionReturnType:
1514 **AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <AlwaysBreakAfterDefinitionReturnType>`
1515 The function definition return type breaking style to use. This
1516 option is **deprecated** and is retained for backwards compatibility.
1520 * ``DRTBS_None`` (in configuration: ``None``)
1521 Break after return type automatically.
1522 ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
1524 * ``DRTBS_All`` (in configuration: ``All``)
1525 Always break after the return type.
1527 * ``DRTBS_TopLevel`` (in configuration: ``TopLevel``)
1528 Always break after the return types of top-level functions.
1532 .. _AlwaysBreakAfterReturnType:
1534 **AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``) :versionbadge:`clang-format 3.8` :ref:`¶ <AlwaysBreakAfterReturnType>`
1535 The function declaration return type breaking style to use.
1539 * ``RTBS_None`` (in configuration: ``None``)
1540 Break after return type automatically.
1541 ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
1546 int f() { return 0; };
1549 int f() { return 1; }
1551 * ``RTBS_All`` (in configuration: ``All``)
1552 Always break after the return type.
1569 * ``RTBS_TopLevel`` (in configuration: ``TopLevel``)
1570 Always break after the return types of top-level functions.
1575 int f() { return 0; };
1584 * ``RTBS_AllDefinitions`` (in configuration: ``AllDefinitions``)
1585 Always break after the return type of function definitions.
1601 * ``RTBS_TopLevelDefinitions`` (in configuration: ``TopLevelDefinitions``)
1602 Always break after the return type of top-level definitions.
1607 int f() { return 0; };
1617 .. _AlwaysBreakBeforeMultilineStrings:
1619 **AlwaysBreakBeforeMultilineStrings** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakBeforeMultilineStrings>`
1620 If ``true``, always break before multiline string literals.
1622 This flag is mean to make cases where there are multiple multiline strings
1623 in a file look more consistent. Thus, it will only take effect if wrapping
1624 the string at that point leads to it being indented
1625 ``ContinuationIndentWidth`` spaces from the start of the line.
1630 aaaa = vs. aaaa = "bbbb"
1634 .. _AlwaysBreakTemplateDeclarations:
1636 **AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ <AlwaysBreakTemplateDeclarations>`
1637 The template declaration breaking style to use.
1641 * ``BTDS_No`` (in configuration: ``No``)
1642 Do not force break before declaration.
1643 ``PenaltyBreakTemplateDeclaration`` is taken into account.
1647 template <typename T> T foo() {
1649 template <typename T> T foo(int aaaaaaaaaaaaaaaaaaaaa,
1650 int bbbbbbbbbbbbbbbbbbbbb) {
1653 * ``BTDS_MultiLine`` (in configuration: ``MultiLine``)
1654 Force break after template declaration only when the following
1655 declaration spans multiple lines.
1659 template <typename T> T foo() {
1661 template <typename T>
1662 T foo(int aaaaaaaaaaaaaaaaaaaaa,
1663 int bbbbbbbbbbbbbbbbbbbbb) {
1666 * ``BTDS_Yes`` (in configuration: ``Yes``)
1667 Always break after template declaration.
1671 template <typename T>
1674 template <typename T>
1675 T foo(int aaaaaaaaaaaaaaaaaaaaa,
1676 int bbbbbbbbbbbbbbbbbbbbb) {
1681 .. _AttributeMacros:
1683 **AttributeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <AttributeMacros>`
1684 A vector of strings that should be interpreted as attributes/qualifiers
1685 instead of identifiers. This can be useful for language extensions or
1686 static analyzer annotations.
1692 x = (char *__capability)&y;
1693 int function(void) __unused;
1694 void only_writes_to_buffer(char *__output buffer);
1696 In the .clang-format configuration file, this can be configured like:
1698 .. code-block:: yaml
1700 AttributeMacros: ['__capability', '__output', '__unused']
1702 .. _BinPackArguments:
1704 **BinPackArguments** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackArguments>`
1705 If ``false``, a function call's arguments will either be all on the
1706 same line or will have one line each.
1712 f(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa,
1713 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
1718 f(aaaaaaaaaaaaaaaaaaaa,
1719 aaaaaaaaaaaaaaaaaaaa,
1720 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
1723 .. _BinPackParameters:
1725 **BinPackParameters** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BinPackParameters>`
1726 If ``false``, a function declaration's or function definition's
1727 parameters will either all be on the same line or will have one line each.
1732 void f(int aaaaaaaaaaaaaaaaaaaa, int aaaaaaaaaaaaaaaaaaaa,
1733 int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
1736 void f(int aaaaaaaaaaaaaaaaaaaa,
1737 int aaaaaaaaaaaaaaaaaaaa,
1738 int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
1740 .. _BitFieldColonSpacing:
1742 **BitFieldColonSpacing** (``BitFieldColonSpacingStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BitFieldColonSpacing>`
1743 The BitFieldColonSpacingStyle to use for bitfields.
1747 * ``BFCS_Both`` (in configuration: ``Both``)
1748 Add one space on each side of the ``:``
1754 * ``BFCS_None`` (in configuration: ``None``)
1755 Add no space around the ``:`` (except when needed for
1756 ``AlignConsecutiveBitFields``).
1762 * ``BFCS_Before`` (in configuration: ``Before``)
1763 Add space before the ``:`` only
1769 * ``BFCS_After`` (in configuration: ``After``)
1770 Add space after the ``:`` only (space may be added before if
1771 needed for ``AlignConsecutiveBitFields``).
1781 **BraceWrapping** (``BraceWrappingFlags``) :versionbadge:`clang-format 3.8` :ref:`¶ <BraceWrapping>`
1782 Control of individual brace wrapping cases.
1784 If ``BreakBeforeBraces`` is set to ``BS_Custom``, use this to specify how
1785 each individual brace case should be handled. Otherwise, this is ignored.
1787 .. code-block:: yaml
1790 BreakBeforeBraces: Custom
1794 SplitEmptyFunction: false
1796 Nested configuration flags:
1798 Precise control over the wrapping of braces.
1802 # Should be declared this way:
1803 BreakBeforeBraces: Custom
1807 * ``bool AfterCaseLabel`` Wrap case labels.
1812 switch (foo) { vs. switch (foo) {
1824 * ``bool AfterClass`` Wrap class definitions.
1835 * ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
1836 Wrap control statements (``if``/``for``/``while``/``switch``/..).
1840 * ``BWACS_Never`` (in configuration: ``Never``)
1841 Never wrap braces after a control statement.
1848 for (int i = 0; i < 10; ++i) {
1851 * ``BWACS_MultiLine`` (in configuration: ``MultiLine``)
1852 Only wrap braces after a multi-line control statement.
1861 while (foo || bar) {
1864 * ``BWACS_Always`` (in configuration: ``Always``)
1865 Always wrap braces after a control statement.
1873 for (int i = 0; i < 10; ++i)
1877 * ``bool AfterEnum`` Wrap enum definitions.
1890 * ``bool AfterFunction`` Wrap function definitions.
1907 * ``bool AfterNamespace`` Wrap namespace definitions.
1924 * ``bool AfterObjCDeclaration`` Wrap ObjC definitions (interfaces, implementations...).
1928 @autoreleasepool and @synchronized blocks are wrapped
1929 according to ``AfterControlStatement`` flag.
1931 * ``bool AfterStruct`` Wrap struct definitions.
1946 * ``bool AfterUnion`` Wrap union definitions.
1961 * ``bool AfterExternBlock`` Wrap extern blocks.
1976 * ``bool BeforeCatch`` Wrap before ``catch``.
1993 * ``bool BeforeElse`` Wrap before ``else``.
2008 * ``bool BeforeLambdaBody`` Wrap lambda block.
2026 * ``bool BeforeWhile`` Wrap before ``while``.
2041 * ``bool IndentBraces`` Indent the wrapped braces themselves.
2043 * ``bool SplitEmptyFunction`` If ``false``, empty function body can be put on a single line.
2044 This option is used only if the opening brace of the function has
2045 already been wrapped, i.e. the ``AfterFunction`` brace wrapping mode is
2046 set, and the function could/should not be put on a single line (as per
2047 ``AllowShortFunctionsOnASingleLine`` and constructor formatting
2057 * ``bool SplitEmptyRecord`` If ``false``, empty record (e.g. class, struct or union) body
2058 can be put on a single line. This option is used only if the opening
2059 brace of the record has already been wrapped, i.e. the ``AfterClass``
2060 (for classes) brace wrapping mode is set.
2065 class Foo vs. class Foo
2069 * ``bool SplitEmptyNamespace`` If ``false``, empty namespace body can be put on a single line.
2070 This option is used only if the opening brace of the namespace has
2071 already been wrapped, i.e. the ``AfterNamespace`` brace wrapping mode is
2077 namespace Foo vs. namespace Foo
2082 .. _BracedInitializerIndentWidth:
2084 **BracedInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 17` :ref:`¶ <BracedInitializerIndentWidth>`
2085 The number of columns to use to indent the contents of braced init lists.
2086 If unset, ``ContinuationIndentWidth`` is used.
2090 AlignAfterOpenBracket: AlwaysBreak
2091 BracedInitializerIndentWidth: 2
2099 auto s = SomeStruct{
2117 .. _BreakAdjacentStringLiterals:
2119 **BreakAdjacentStringLiterals** (``Boolean``) :versionbadge:`clang-format 18` :ref:`¶ <BreakAdjacentStringLiterals>`
2120 Break between adjacent string literals.
2130 return "Code" "\0\52\26\55\55\0" "x013" "\02\xBA";
2132 .. _BreakAfterAttributes:
2134 **BreakAfterAttributes** (``AttributeBreakingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakAfterAttributes>`
2135 Break after a group of C++11 attributes before variable or function
2136 (including constructor/destructor) declaration/definition names or before
2137 control statements, i.e. ``if``, ``switch`` (including ``case`` and
2138 ``default`` labels), ``for``, and ``while`` statements.
2142 * ``ABS_Always`` (in configuration: ``Always``)
2143 Always break after attributes.
2149 [[gnu::const]] [[maybe_unused]]
2154 [[gnu::const]] [[nodiscard]]
2173 * ``ABS_Leave`` (in configuration: ``Leave``)
2174 Leave the line breaking after attributes as is.
2178 [[maybe_unused]] const int i;
2179 [[gnu::const]] [[maybe_unused]]
2182 [[nodiscard]] inline int f();
2183 [[gnu::const]] [[nodiscard]]
2192 [[unlikely]] case 1:
2200 * ``ABS_Never`` (in configuration: ``Never``)
2201 Never break after attributes.
2205 [[maybe_unused]] const int i;
2206 [[gnu::const]] [[maybe_unused]] int j;
2208 [[nodiscard]] inline int f();
2209 [[gnu::const]] [[nodiscard]] int g();
2217 [[unlikely]] case 1:
2226 .. _BreakAfterJavaFieldAnnotations:
2228 **BreakAfterJavaFieldAnnotations** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ <BreakAfterJavaFieldAnnotations>`
2229 Break after each annotation on a field in Java files.
2231 .. code-block:: java
2234 @Partial vs. @Partial @Mock DataLoad loader;
2240 **BreakArrays** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <BreakArrays>`
2241 If ``true``, clang-format will always break after a Json array ``[``
2242 otherwise it will scan until the closing ``]`` to determine if it should
2243 add newlines between elements (prettier compatible).
2248 This is currently only for formatting JSON.
2260 .. _BreakBeforeBinaryOperators:
2262 **BreakBeforeBinaryOperators** (``BinaryOperatorStyle``) :versionbadge:`clang-format 3.6` :ref:`¶ <BreakBeforeBinaryOperators>`
2263 The way to wrap binary operators.
2267 * ``BOS_None`` (in configuration: ``None``)
2268 Break after operators.
2272 LooooooooooongType loooooooooooooooooooooongVariable =
2273 someLooooooooooooooooongFunction();
2275 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
2276 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
2277 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
2278 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
2279 ccccccccccccccccccccccccccccccccccccccccc;
2281 * ``BOS_NonAssignment`` (in configuration: ``NonAssignment``)
2282 Break before operators that aren't assignments.
2286 LooooooooooongType loooooooooooooooooooooongVariable =
2287 someLooooooooooooooooongFunction();
2289 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2290 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2291 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2292 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2293 > ccccccccccccccccccccccccccccccccccccccccc;
2295 * ``BOS_All`` (in configuration: ``All``)
2296 Break before operators.
2300 LooooooooooongType loooooooooooooooooooooongVariable
2301 = someLooooooooooooooooongFunction();
2303 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2304 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2305 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2306 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2307 > ccccccccccccccccccccccccccccccccccccccccc;
2311 .. _BreakBeforeBraces:
2313 **BreakBeforeBraces** (``BraceBreakingStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeBraces>`
2314 The brace breaking style to use.
2318 * ``BS_Attach`` (in configuration: ``Attach``)
2319 Always attach braces to surrounding context.
2362 void bar() { foo(true); }
2365 * ``BS_Linux`` (in configuration: ``Linux``)
2366 Like ``Attach``, but break before braces on function, namespace and
2414 void bar() { foo(true); }
2417 * ``BS_Mozilla`` (in configuration: ``Mozilla``)
2418 Like ``Attach``, but break before braces on enum, function, and record
2466 void bar() { foo(true); }
2469 * ``BS_Stroustrup`` (in configuration: ``Stroustrup``)
2470 Like ``Attach``, but break before function definitions, ``catch``, and
2518 void bar() { foo(true); }
2521 * ``BS_Allman`` (in configuration: ``Allman``)
2522 Always break before braces.
2580 void bar() { foo(true); }
2583 * ``BS_Whitesmiths`` (in configuration: ``Whitesmiths``)
2584 Like ``Allman`` but always indent braces and line up code with braces.
2642 void bar() { foo(true); }
2645 * ``BS_GNU`` (in configuration: ``GNU``)
2646 Always break before braces and add an extra level of indentation to
2647 braces of control statements, not to those of class, function
2648 or other definitions.
2707 void bar() { foo(true); }
2710 * ``BS_WebKit`` (in configuration: ``WebKit``)
2711 Like ``Attach``, but break before functions.
2756 void bar() { foo(true); }
2759 * ``BS_Custom`` (in configuration: ``Custom``)
2760 Configure each individual brace in ``BraceWrapping``.
2764 .. _BreakBeforeConceptDeclarations:
2766 **BreakBeforeConceptDeclarations** (``BreakBeforeConceptDeclarationsStyle``) :versionbadge:`clang-format 12` :ref:`¶ <BreakBeforeConceptDeclarations>`
2767 The concept declaration style to use.
2771 * ``BBCDS_Never`` (in configuration: ``Never``)
2772 Keep the template declaration line together with ``concept``.
2776 template <typename T> concept C = ...;
2778 * ``BBCDS_Allowed`` (in configuration: ``Allowed``)
2779 Breaking between template declaration and ``concept`` is allowed. The
2780 actual behavior depends on the content and line breaking rules and
2783 * ``BBCDS_Always`` (in configuration: ``Always``)
2784 Always break before ``concept``, putting it in the line after the
2785 template declaration.
2789 template <typename T>
2794 .. _BreakBeforeInlineASMColon:
2796 **BreakBeforeInlineASMColon** (``BreakBeforeInlineASMColonStyle``) :versionbadge:`clang-format 16` :ref:`¶ <BreakBeforeInlineASMColon>`
2797 The inline ASM colon style to use.
2801 * ``BBIAS_Never`` (in configuration: ``Never``)
2802 No break before inline ASM colon.
2806 asm volatile("string", : : val);
2808 * ``BBIAS_OnlyMultiline`` (in configuration: ``OnlyMultiline``)
2809 Break before inline ASM colon if the line length is longer than column
2814 asm volatile("string", : : val);
2815 asm("cmoveq %1, %2, %[result]"
2816 : [result] "=r"(result)
2817 : "r"(test), "r"(new), "[result]"(old));
2819 * ``BBIAS_Always`` (in configuration: ``Always``)
2820 Always break before inline ASM colon.
2824 asm volatile("string",
2830 .. _BreakBeforeTernaryOperators:
2832 **BreakBeforeTernaryOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <BreakBeforeTernaryOperators>`
2833 If ``true``, ternary operators will be placed after line breaks.
2838 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription
2840 : SecondValueVeryVeryVeryVeryLong;
2843 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription ?
2845 SecondValueVeryVeryVeryVeryLong;
2847 .. _BreakConstructorInitializers:
2849 **BreakConstructorInitializers** (``BreakConstructorInitializersStyle``) :versionbadge:`clang-format 5` :ref:`¶ <BreakConstructorInitializers>`
2850 The break constructor initializers style to use.
2854 * ``BCIS_BeforeColon`` (in configuration: ``BeforeColon``)
2855 Break constructor initializers before the colon and after the commas.
2863 * ``BCIS_BeforeComma`` (in configuration: ``BeforeComma``)
2864 Break constructor initializers before the colon and commas, and align
2865 the commas with the colon.
2873 * ``BCIS_AfterColon`` (in configuration: ``AfterColon``)
2874 Break constructor initializers after the colon and commas.
2884 .. _BreakInheritanceList:
2886 **BreakInheritanceList** (``BreakInheritanceListStyle``) :versionbadge:`clang-format 7` :ref:`¶ <BreakInheritanceList>`
2887 The inheritance list style to use.
2891 * ``BILS_BeforeColon`` (in configuration: ``BeforeColon``)
2892 Break inheritance list before the colon and after the commas.
2901 * ``BILS_BeforeComma`` (in configuration: ``BeforeComma``)
2902 Break inheritance list before the colon and commas, and align
2903 the commas with the colon.
2912 * ``BILS_AfterColon`` (in configuration: ``AfterColon``)
2913 Break inheritance list after the colon and commas.
2922 * ``BILS_AfterComma`` (in configuration: ``AfterComma``)
2923 Break inheritance list only after the commas.
2933 .. _BreakStringLiterals:
2935 **BreakStringLiterals** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <BreakStringLiterals>`
2936 Allow breaking string literals when formatting.
2938 In C, C++, and Objective-C:
2943 const char* x = "veryVeryVeryVeryVeryVe"
2944 "ryVeryVeryVeryVeryVery"
2949 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
2956 string x = "veryVeryVeryVeryVeryVe" +
2957 "ryVeryVeryVeryVeryVery" +
2962 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
2964 C# interpolated strings are not broken.
2971 string x = {"veryVeryVeryVeryVeryVe",
2972 "ryVeryVeryVeryVeryVery",
2977 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
2981 **ColumnLimit** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ColumnLimit>`
2984 A column limit of ``0`` means that there is no column limit. In this case,
2985 clang-format will respect the input's line breaking decisions within
2986 statements unless they contradict other rules.
2990 **CommentPragmas** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <CommentPragmas>`
2991 A regular expression that describes comments with special meaning,
2992 which should not be split into lines or otherwise changed.
2996 // CommentPragmas: '^ FOOBAR pragma:'
2997 // Will leave the following line unaffected
2998 #include <vector> // FOOBAR pragma: keep
3000 .. _CompactNamespaces:
3002 **CompactNamespaces** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <CompactNamespaces>`
3003 If ``true``, consecutive namespace declarations will be on the same
3004 line. If ``false``, each namespace is declared on a new line.
3009 namespace Foo { namespace Bar {
3018 If it does not fit on a single line, the overflowing namespaces get
3023 namespace Foo { namespace Bar {
3027 .. _ConstructorInitializerAllOnOneLineOrOnePerLine:
3029 **ConstructorInitializerAllOnOneLineOrOnePerLine** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerAllOnOneLineOrOnePerLine>`
3030 This option is **deprecated**. See ``CurrentLine`` of
3031 ``PackConstructorInitializers``.
3033 .. _ConstructorInitializerIndentWidth:
3035 **ConstructorInitializerIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ConstructorInitializerIndentWidth>`
3036 The number of characters to use for indentation of constructor
3037 initializer lists as well as inheritance lists.
3039 .. _ContinuationIndentWidth:
3041 **ContinuationIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ContinuationIndentWidth>`
3042 Indent width for line continuations.
3046 ContinuationIndentWidth: 2
3048 int i = // VeryVeryVeryVeryVeryLongComment
3049 longFunction( // Again a long comment
3052 .. _Cpp11BracedListStyle:
3054 **Cpp11BracedListStyle** (``Boolean``) :versionbadge:`clang-format 3.4` :ref:`¶ <Cpp11BracedListStyle>`
3055 If ``true``, format braced lists as best suited for C++11 braced
3058 Important differences:
3059 - No spaces inside the braced list.
3060 - No line break before the closing brace.
3061 - Indentation with the continuation indent, not with the block indent.
3063 Fundamentally, C++11 braced lists are formatted exactly like function
3064 calls would be formatted in their place. If the braced list follows a name
3065 (e.g. a type or variable name), clang-format formats as if the ``{}`` were
3066 the parentheses of a function call with that name. If there is no name,
3067 a zero-length name is assumed.
3072 vector<int> x{1, 2, 3, 4}; vs. vector<int> x{ 1, 2, 3, 4 };
3073 vector<T> x{{}, {}, {}, {}}; vector<T> x{ {}, {}, {}, {} };
3074 f(MyMap[{composite, key}]); f(MyMap[{ composite, key }]);
3075 new int[3]{1, 2, 3}; new int[3]{ 1, 2, 3 };
3077 .. _DeriveLineEnding:
3079 **DeriveLineEnding** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <DeriveLineEnding>`
3080 This option is **deprecated**. See ``DeriveLF`` and ``DeriveCRLF`` of
3083 .. _DerivePointerAlignment:
3085 **DerivePointerAlignment** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DerivePointerAlignment>`
3086 If ``true``, analyze the formatted file for the most common
3087 alignment of ``&`` and ``*``.
3088 Pointer and reference alignment styles are going to be updated according
3089 to the preferences found in the file.
3090 ``PointerAlignment`` is then used only as fallback.
3094 **DisableFormat** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <DisableFormat>`
3095 Disables formatting completely.
3097 .. _EmptyLineAfterAccessModifier:
3099 **EmptyLineAfterAccessModifier** (``EmptyLineAfterAccessModifierStyle``) :versionbadge:`clang-format 13` :ref:`¶ <EmptyLineAfterAccessModifier>`
3100 Defines when to put an empty line after access modifiers.
3101 ``EmptyLineBeforeAccessModifier`` configuration handles the number of
3102 empty lines between two access modifiers.
3106 * ``ELAAMS_Never`` (in configuration: ``Never``)
3107 Remove all empty lines after access modifiers.
3123 * ``ELAAMS_Leave`` (in configuration: ``Leave``)
3124 Keep existing empty lines after access modifiers.
3125 MaxEmptyLinesToKeep is applied instead.
3127 * ``ELAAMS_Always`` (in configuration: ``Always``)
3128 Always add empty line after access modifiers if there are none.
3129 MaxEmptyLinesToKeep is applied also.
3152 .. _EmptyLineBeforeAccessModifier:
3154 **EmptyLineBeforeAccessModifier** (``EmptyLineBeforeAccessModifierStyle``) :versionbadge:`clang-format 12` :ref:`¶ <EmptyLineBeforeAccessModifier>`
3155 Defines in which cases to put empty line before access modifiers.
3159 * ``ELBAMS_Never`` (in configuration: ``Never``)
3160 Remove all empty lines before access modifiers.
3176 * ``ELBAMS_Leave`` (in configuration: ``Leave``)
3177 Keep existing empty lines before access modifiers.
3179 * ``ELBAMS_LogicalBlock`` (in configuration: ``LogicalBlock``)
3180 Add empty line only when access modifier starts a new logical block.
3181 Logical block is a group of one or more member fields or functions.
3199 * ``ELBAMS_Always`` (in configuration: ``Always``)
3200 Always add empty line before access modifiers unless access modifier
3201 is at the start of struct or class definition.
3223 .. _ExperimentalAutoDetectBinPacking:
3225 **ExperimentalAutoDetectBinPacking** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ExperimentalAutoDetectBinPacking>`
3226 If ``true``, clang-format detects whether function calls and
3227 definitions are formatted with one parameter per line.
3229 Each call can be bin-packed, one-per-line or inconclusive. If it is
3230 inconclusive, e.g. completely on one line, but a decision needs to be
3231 made, clang-format analyzes whether there are other bin-packed cases in
3232 the input file and act accordingly.
3237 This is an experimental flag, that might go away or be renamed. Do
3238 not use this in config files, etc. Use at your own risk.
3240 .. _FixNamespaceComments:
3242 **FixNamespaceComments** (``Boolean``) :versionbadge:`clang-format 5` :ref:`¶ <FixNamespaceComments>`
3243 If ``true``, clang-format adds missing namespace end comments for
3244 namespaces and fixes invalid existing ones. This doesn't affect short
3245 namespaces, which are controlled by ``ShortNamespaceLines``.
3250 namespace longNamespace { vs. namespace longNamespace {
3251 void foo(); void foo();
3252 void bar(); void bar();
3254 namespace shortNamespace { namespace shortNamespace {
3255 void baz(); void baz();
3260 **ForEachMacros** (``List of Strings``) :versionbadge:`clang-format 3.7` :ref:`¶ <ForEachMacros>`
3261 A vector of macros that should be interpreted as foreach loops
3262 instead of as function calls.
3264 These are expected to be macros of the form:
3268 FOREACH(<variable-declaration>, ...)
3271 In the .clang-format configuration file, this can be configured like:
3273 .. code-block:: yaml
3275 ForEachMacros: ['RANGES_FOR', 'FOREACH']
3277 For example: BOOST_FOREACH.
3281 **IfMacros** (``List of Strings``) :versionbadge:`clang-format 13` :ref:`¶ <IfMacros>`
3282 A vector of macros that should be interpreted as conditionals
3283 instead of as function calls.
3285 These are expected to be macros of the form:
3294 In the .clang-format configuration file, this can be configured like:
3296 .. code-block:: yaml
3300 For example: `KJ_IF_MAYBE
3301 <https://github.com/capnproto/capnproto/blob/master/kjdoc/tour.md#maybes>`_
3305 **IncludeBlocks** (``IncludeBlocksStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IncludeBlocks>`
3306 Dependent on the value, multiple ``#include`` blocks can be sorted
3307 as one and divided based on category.
3311 * ``IBS_Preserve`` (in configuration: ``Preserve``)
3312 Sort each ``#include`` block separately.
3316 #include "b.h" into #include "b.h"
3318 #include <lib/main.h> #include "a.h"
3319 #include "a.h" #include <lib/main.h>
3321 * ``IBS_Merge`` (in configuration: ``Merge``)
3322 Merge multiple ``#include`` blocks together and sort as one.
3326 #include "b.h" into #include "a.h"
3328 #include <lib/main.h> #include <lib/main.h>
3331 * ``IBS_Regroup`` (in configuration: ``Regroup``)
3332 Merge multiple ``#include`` blocks together and sort as one.
3333 Then split into groups based on category priority. See
3334 ``IncludeCategories``.
3338 #include "b.h" into #include "a.h"
3340 #include <lib/main.h>
3341 #include "a.h" #include <lib/main.h>
3345 .. _IncludeCategories:
3347 **IncludeCategories** (``List of IncludeCategories``) :versionbadge:`clang-format 3.8` :ref:`¶ <IncludeCategories>`
3348 Regular expressions denoting the different ``#include`` categories
3349 used for ordering ``#includes``.
3352 <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
3353 regular expressions are supported.
3355 These regular expressions are matched against the filename of an include
3356 (including the <> or "") in order. The value belonging to the first
3357 matching regular expression is assigned and ``#includes`` are sorted first
3358 according to increasing category number and then alphabetically within
3361 If none of the regular expressions match, INT_MAX is assigned as
3362 category. The main header for a source file automatically gets category 0.
3363 so that it is generally kept at the beginning of the ``#includes``
3364 (https://llvm.org/docs/CodingStandards.html#include-style). However, you
3365 can also assign negative priorities if you have certain headers that
3366 always need to be first.
3368 There is a third and optional field ``SortPriority`` which can used while
3369 ``IncludeBlocks = IBS_Regroup`` to define the priority in which
3370 ``#includes`` should be ordered. The value of ``Priority`` defines the
3371 order of ``#include blocks`` and also allows the grouping of ``#includes``
3372 of different priority. ``SortPriority`` is set to the value of
3373 ``Priority`` as default if it is not assigned.
3375 Each regular expression can be marked as case sensitive with the field
3376 ``CaseSensitive``, per default it is not.
3378 To configure this in the .clang-format file, use:
3380 .. code-block:: yaml
3383 - Regex: '^"(llvm|llvm-c|clang|clang-c)/'
3387 - Regex: '^((<|")(gtest|gmock|isl|json)/)'
3389 - Regex: '<[[:alnum:].]+>'
3395 .. _IncludeIsMainRegex:
3397 **IncludeIsMainRegex** (``String``) :versionbadge:`clang-format 3.9` :ref:`¶ <IncludeIsMainRegex>`
3398 Specify a regular expression of suffixes that are allowed in the
3399 file-to-main-include mapping.
3401 When guessing whether a #include is the "main" include (to assign
3402 category 0, see above), use this regex of allowed suffixes to the header
3403 stem. A partial match is done, so that:
3404 - "" means "arbitrary suffix"
3405 - "$" means "no suffix"
3407 For example, if configured to "(_test)?$", then a header a.h would be seen
3408 as the "main" include in both a.cc and a_test.cc.
3410 .. _IncludeIsMainSourceRegex:
3412 **IncludeIsMainSourceRegex** (``String``) :versionbadge:`clang-format 10` :ref:`¶ <IncludeIsMainSourceRegex>`
3413 Specify a regular expression for files being formatted
3414 that are allowed to be considered "main" in the
3415 file-to-main-include mapping.
3417 By default, clang-format considers files as "main" only when they end
3418 with: ``.c``, ``.cc``, ``.cpp``, ``.c++``, ``.cxx``, ``.m`` or ``.mm``
3420 For these files a guessing of "main" include takes place
3421 (to assign category 0, see above). This config option allows for
3422 additional suffixes and extensions for files to be considered as "main".
3424 For example, if this option is configured to ``(Impl\.hpp)$``,
3425 then a file ``ClassImpl.hpp`` is considered "main" (in addition to
3426 ``Class.c``, ``Class.cc``, ``Class.cpp`` and so on) and "main
3427 include file" logic will be executed (with *IncludeIsMainRegex* setting
3428 also being respected in later phase). Without this option set,
3429 ``ClassImpl.hpp`` would not have the main include file put on top
3430 before any other include.
3432 .. _IndentAccessModifiers:
3434 **IndentAccessModifiers** (``Boolean``) :versionbadge:`clang-format 13` :ref:`¶ <IndentAccessModifiers>`
3435 Specify whether access modifiers should have their own indentation level.
3437 When ``false``, access modifiers are indented (or outdented) relative to
3438 the record members, respecting the ``AccessModifierOffset``. Record
3439 members are indented one level below the record.
3440 When ``true``, access modifiers get their own indentation level. As a
3441 consequence, record members are always indented 2 levels below the record,
3442 regardless of the access modifier presence. Value of the
3443 ``AccessModifierOffset`` is ignored.
3448 class C { vs. class C {
3450 void bar(); void bar();
3451 protected: protected:
3457 void foo() { void foo() {
3461 .. _IndentCaseBlocks:
3463 **IndentCaseBlocks** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <IndentCaseBlocks>`
3464 Indent case label blocks one level from the case label.
3466 When ``false``, the block following the case label uses the same
3467 indentation level as for the case label, treating the case label the same
3469 When ``true``, the block gets indented as a scope block.
3474 switch (fool) { vs. switch (fool) {
3486 .. _IndentCaseLabels:
3488 **IndentCaseLabels** (``Boolean``) :versionbadge:`clang-format 3.3` :ref:`¶ <IndentCaseLabels>`
3489 Indent case labels one level from the switch statement.
3491 When ``false``, use the same indentation level as for the switch
3492 statement. Switch statement body is always indented one level more than
3493 case labels (except the first block following the case label, which
3494 itself indents the code - unless IndentCaseBlocks is enabled).
3499 switch (fool) { vs. switch (fool) {
3507 .. _IndentExternBlock:
3509 **IndentExternBlock** (``IndentExternBlockStyle``) :versionbadge:`clang-format 11` :ref:`¶ <IndentExternBlock>`
3510 IndentExternBlockStyle is the type of indenting of extern blocks.
3514 * ``IEBS_AfterExternBlock`` (in configuration: ``AfterExternBlock``)
3515 Backwards compatible with AfterExternBlock's indenting.
3519 IndentExternBlock: AfterExternBlock
3520 BraceWrapping.AfterExternBlock: true
3529 IndentExternBlock: AfterExternBlock
3530 BraceWrapping.AfterExternBlock: false
3535 * ``IEBS_NoIndent`` (in configuration: ``NoIndent``)
3536 Does not indent extern blocks.
3544 * ``IEBS_Indent`` (in configuration: ``Indent``)
3545 Indents extern blocks.
3555 .. _IndentGotoLabels:
3557 **IndentGotoLabels** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <IndentGotoLabels>`
3560 When ``false``, goto labels are flushed left.
3565 int f() { vs. int f() {
3566 if (foo()) { if (foo()) {
3574 .. _IndentPPDirectives:
3576 **IndentPPDirectives** (``PPDirectiveIndentStyle``) :versionbadge:`clang-format 6` :ref:`¶ <IndentPPDirectives>`
3577 The preprocessor directive indenting style to use.
3581 * ``PPDIS_None`` (in configuration: ``None``)
3582 Does not indent any directives.
3592 * ``PPDIS_AfterHash`` (in configuration: ``AfterHash``)
3593 Indents directives after the hash.
3603 * ``PPDIS_BeforeHash`` (in configuration: ``BeforeHash``)
3604 Indents directives before the hash.
3616 .. _IndentRequiresClause:
3618 **IndentRequiresClause** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <IndentRequiresClause>`
3619 Indent the requires clause in a template. This only applies when
3620 ``RequiresClausePosition`` is ``OwnLine``, or ``WithFollowing``.
3622 In clang-format 12, 13 and 14 it was named ``IndentRequires``.
3627 template <typename It>
3628 requires Iterator<It>
3629 void sort(It begin, It end) {
3634 template <typename It>
3635 requires Iterator<It>
3636 void sort(It begin, It end) {
3642 **IndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWidth>`
3643 The number of columns to use for indentation.
3656 .. _IndentWrappedFunctionNames:
3658 **IndentWrappedFunctionNames** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <IndentWrappedFunctionNames>`
3659 Indent if a function definition or declaration is wrapped after the
3665 LoooooooooooooooooooooooooooooooooooooooongReturnType
3666 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
3669 LoooooooooooooooooooooooooooooooooooooooongReturnType
3670 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
3674 **InsertBraces** (``Boolean``) :versionbadge:`clang-format 15` :ref:`¶ <InsertBraces>`
3675 Insert braces after control statements (``if``, ``else``, ``for``, ``do``,
3676 and ``while``) in C++ unless the control statements are inside macro
3677 definitions or the braces would enclose preprocessor directives.
3681 Setting this option to ``true`` could lead to incorrect code formatting
3682 due to clang-format's lack of complete semantic information. As such,
3683 extra care should be taken to review code changes made by this option.
3689 if (isa<FunctionDecl>(D)) vs. if (isa<FunctionDecl>(D)) {
3690 handleFunctionDecl(D); handleFunctionDecl(D);
3691 else if (isa<VarDecl>(D)) } else if (isa<VarDecl>(D)) {
3692 handleVarDecl(D); handleVarDecl(D);
3697 while (i--) vs. while (i--) {
3698 for (auto *A : D.attrs()) for (auto *A : D.attrs()) {
3699 handleAttr(A); handleAttr(A);
3705 while (i); } while (i);
3707 .. _InsertNewlineAtEOF:
3709 **InsertNewlineAtEOF** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <InsertNewlineAtEOF>`
3710 Insert a newline at end of file if missing.
3712 .. _InsertTrailingCommas:
3714 **InsertTrailingCommas** (``TrailingCommaStyle``) :versionbadge:`clang-format 11` :ref:`¶ <InsertTrailingCommas>`
3715 If set to ``TCS_Wrapped`` will insert trailing commas in container
3716 literals (arrays and objects) that wrap across multiple lines.
3717 It is currently only available for JavaScript
3718 and disabled by default ``TCS_None``.
3719 ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
3720 as inserting the comma disables bin-packing.
3726 aaaaaaaaaaaaaaaaaaaaaaaaaa,
3727 aaaaaaaaaaaaaaaaaaaaaaaaaa,
3728 aaaaaaaaaaaaaaaaaaaaaaaaaa,
3734 * ``TCS_None`` (in configuration: ``None``)
3735 Do not insert trailing commas.
3737 * ``TCS_Wrapped`` (in configuration: ``Wrapped``)
3738 Insert trailing commas in container literals that were wrapped over
3739 multiple lines. Note that this is conceptually incompatible with
3740 bin-packing, because the trailing comma is used as an indicator
3741 that a container should be formatted one-per-line (i.e. not bin-packed).
3742 So inserting a trailing comma counteracts bin-packing.
3746 .. _IntegerLiteralSeparator:
3748 **IntegerLiteralSeparator** (``IntegerLiteralSeparatorStyle``) :versionbadge:`clang-format 16` :ref:`¶ <IntegerLiteralSeparator>`
3749 Format integer literal separators (``'`` for C++ and ``_`` for C#, Java,
3752 Nested configuration flags:
3754 Separator format of integer literals of different bases.
3756 If negative, remove separators. If ``0``, leave the literal as is. If
3757 positive, insert separators between digits starting from the rightmost
3760 For example, the config below will leave separators in binary literals
3761 alone, insert separators in decimal literals to separate the digits into
3762 groups of 3, and remove separators in hexadecimal literals.
3766 IntegerLiteralSeparator:
3771 You can also specify a minimum number of digits (``BinaryMinDigits``,
3772 ``DecimalMinDigits``, and ``HexMinDigits``) the integer literal must
3773 have in order for the separators to be inserted.
3775 * ``int8_t Binary`` Format separators in binary literals.
3777 .. code-block:: text
3779 /* -1: */ b = 0b100111101101;
3780 /* 0: */ b = 0b10011'11'0110'1;
3781 /* 3: */ b = 0b100'111'101'101;
3782 /* 4: */ b = 0b1001'1110'1101;
3784 * ``int8_t BinaryMinDigits`` Format separators in binary literals with a minimum number of digits.
3786 .. code-block:: text
3789 // BinaryMinDigits: 7
3793 * ``int8_t Decimal`` Format separators in decimal literals.
3795 .. code-block:: text
3797 /* -1: */ d = 18446744073709550592ull;
3798 /* 0: */ d = 184467'440737'0'95505'92ull;
3799 /* 3: */ d = 18'446'744'073'709'550'592ull;
3801 * ``int8_t DecimalMinDigits`` Format separators in decimal literals with a minimum number of digits.
3803 .. code-block:: text
3806 // DecimalMinDigits: 5
3810 * ``int8_t Hex`` Format separators in hexadecimal literals.
3812 .. code-block:: text
3814 /* -1: */ h = 0xDEADBEEFDEADBEEFuz;
3815 /* 0: */ h = 0xDEAD'BEEF'DE'AD'BEE'Fuz;
3816 /* 2: */ h = 0xDE'AD'BE'EF'DE'AD'BE'EFuz;
3818 * ``int8_t HexMinDigits`` Format separators in hexadecimal literals with a minimum number of
3821 .. code-block:: text
3829 .. _JavaImportGroups:
3831 **JavaImportGroups** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <JavaImportGroups>`
3832 A vector of prefixes ordered by the desired groups for Java imports.
3834 One group's prefix can be a subset of another - the longest prefix is
3835 always matched. Within a group, the imports are ordered lexicographically.
3836 Static imports are grouped separately and follow the same group rules.
3837 By default, static imports are placed before non-static imports,
3838 but this behavior is changed by another option,
3839 ``SortJavaStaticImport``.
3841 In the .clang-format configuration file, this can be configured like
3842 in the following yaml example. This will result in imports being
3843 formatted as in the Java example below.
3845 .. code-block:: yaml
3847 JavaImportGroups: ['com.example', 'com', 'org']
3850 .. code-block:: java
3852 import static com.example.function1;
3854 import static com.test.function2;
3856 import static org.example.function3;
3858 import com.example.ClassA;
3859 import com.example.Test;
3860 import com.example.a.ClassB;
3862 import com.test.ClassC;
3864 import org.example.ClassD;
3866 .. _JavaScriptQuotes:
3868 **JavaScriptQuotes** (``JavaScriptQuoteStyle``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptQuotes>`
3869 The JavaScriptQuoteStyle to use for JavaScript strings.
3873 * ``JSQS_Leave`` (in configuration: ``Leave``)
3874 Leave string quotes as they are.
3881 * ``JSQS_Single`` (in configuration: ``Single``)
3882 Always use single quotes.
3889 * ``JSQS_Double`` (in configuration: ``Double``)
3890 Always use double quotes.
3899 .. _JavaScriptWrapImports:
3901 **JavaScriptWrapImports** (``Boolean``) :versionbadge:`clang-format 3.9` :ref:`¶ <JavaScriptWrapImports>`
3902 Whether to wrap JavaScript import/export statements.
3908 VeryLongImportsAreAnnoying,
3909 VeryLongImportsAreAnnoying,
3910 VeryLongImportsAreAnnoying,
3911 } from 'some/module.js'
3914 import {VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying,} from "some/module.js"
3916 .. _KeepEmptyLinesAtEOF:
3918 **KeepEmptyLinesAtEOF** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <KeepEmptyLinesAtEOF>`
3919 Keep empty lines (up to ``MaxEmptyLinesToKeep``) at end of file.
3921 .. _KeepEmptyLinesAtTheStartOfBlocks:
3923 **KeepEmptyLinesAtTheStartOfBlocks** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <KeepEmptyLinesAtTheStartOfBlocks>`
3924 If true, the empty line at the start of blocks is kept.
3929 if (foo) { vs. if (foo) {
3934 .. _LambdaBodyIndentation:
3936 **LambdaBodyIndentation** (``LambdaBodyIndentationKind``) :versionbadge:`clang-format 13` :ref:`¶ <LambdaBodyIndentation>`
3937 The indentation style of lambda bodies. ``Signature`` (the default)
3938 causes the lambda body to be indented one additional level relative to
3939 the indentation level of the signature. ``OuterScope`` forces the lambda
3940 body to be indented one additional level relative to the parent scope
3941 containing the lambda signature.
3945 * ``LBI_Signature`` (in configuration: ``Signature``)
3946 Align lambda body relative to the lambda signature. This is the default.
3951 [](SomeReallyLongLambdaSignatureArgument foo) {
3955 * ``LBI_OuterScope`` (in configuration: ``OuterScope``)
3956 For statements within block scope, align lambda body relative to the
3957 indentation level of the outer scope the lambda signature resides in.
3962 [](SomeReallyLongLambdaSignatureArgument foo) {
3966 someMethod(someOtherMethod(
3967 [](SomeReallyLongLambdaSignatureArgument foo) {
3975 **Language** (``LanguageKind``) :versionbadge:`clang-format 3.5` :ref:`¶ <Language>`
3976 Language, this format style is targeted at.
3980 * ``LK_None`` (in configuration: ``None``)
3983 * ``LK_Cpp`` (in configuration: ``Cpp``)
3984 Should be used for C, C++.
3986 * ``LK_CSharp`` (in configuration: ``CSharp``)
3987 Should be used for C#.
3989 * ``LK_Java`` (in configuration: ``Java``)
3990 Should be used for Java.
3992 * ``LK_JavaScript`` (in configuration: ``JavaScript``)
3993 Should be used for JavaScript.
3995 * ``LK_Json`` (in configuration: ``Json``)
3996 Should be used for JSON.
3998 * ``LK_ObjC`` (in configuration: ``ObjC``)
3999 Should be used for Objective-C, Objective-C++.
4001 * ``LK_Proto`` (in configuration: ``Proto``)
4002 Should be used for Protocol Buffers
4003 (https://developers.google.com/protocol-buffers/).
4005 * ``LK_TableGen`` (in configuration: ``TableGen``)
4006 Should be used for TableGen code.
4008 * ``LK_TextProto`` (in configuration: ``TextProto``)
4009 Should be used for Protocol Buffer messages in text format
4010 (https://developers.google.com/protocol-buffers/).
4012 * ``LK_Verilog`` (in configuration: ``Verilog``)
4013 Should be used for Verilog and SystemVerilog.
4014 https://standards.ieee.org/ieee/1800/6700/
4015 https://sci-hub.st/10.1109/IEEESTD.2018.8299595
4021 **LineEnding** (``LineEndingStyle``) :versionbadge:`clang-format 16` :ref:`¶ <LineEnding>`
4022 Line ending style (``\n`` or ``\r\n``) to use.
4026 * ``LE_LF`` (in configuration: ``LF``)
4029 * ``LE_CRLF`` (in configuration: ``CRLF``)
4032 * ``LE_DeriveLF`` (in configuration: ``DeriveLF``)
4033 Use ``\n`` unless the input has more lines ending in ``\r\n``.
4035 * ``LE_DeriveCRLF`` (in configuration: ``DeriveCRLF``)
4036 Use ``\r\n`` unless the input has more lines ending in ``\n``.
4040 .. _MacroBlockBegin:
4042 **MacroBlockBegin** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockBegin>`
4043 A regular expression matching macros that start a block.
4048 MacroBlockBegin: "^NS_MAP_BEGIN|\
4073 **MacroBlockEnd** (``String``) :versionbadge:`clang-format 3.7` :ref:`¶ <MacroBlockEnd>`
4074 A regular expression matching macros that end a block.
4078 **Macros** (``List of Strings``) :versionbadge:`clang-format 17` :ref:`¶ <Macros>`
4079 A list of macros of the form ``<definition>=<expansion>`` .
4081 Code will be parsed with macros expanded, in order to determine how to
4082 interpret and format the macro arguments.
4084 For example, the code:
4090 will usually be interpreted as a call to a function A, and the
4091 multiplication expression will be formatted as ``a * b``.
4093 If we specify the macro definition:
4095 .. code-block:: yaml
4100 the code will now be parsed as a declaration of the variable b of type a*,
4101 and formatted as ``a* b`` (depending on pointer-binding rules).
4103 Features and restrictions:
4104 * Both function-like macros and object-like macros are supported.
4105 * Macro arguments must be used exactly once in the expansion.
4106 * No recursive expansion; macros referencing other macros will be
4108 * Overloading by arity is supported: for example, given the macro
4109 definitions A=x, A()=y, A(a)=a
4117 A(a, b); // will not be expanded.
4119 .. _MaxEmptyLinesToKeep:
4121 **MaxEmptyLinesToKeep** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <MaxEmptyLinesToKeep>`
4122 The maximum number of consecutive empty lines to keep.
4126 MaxEmptyLinesToKeep: 1 vs. MaxEmptyLinesToKeep: 0
4130 i = foo(); return i;
4135 .. _NamespaceIndentation:
4137 **NamespaceIndentation** (``NamespaceIndentationKind``) :versionbadge:`clang-format 3.7` :ref:`¶ <NamespaceIndentation>`
4138 The indentation used for namespaces.
4142 * ``NI_None`` (in configuration: ``None``)
4143 Don't indent in namespaces.
4154 * ``NI_Inner`` (in configuration: ``Inner``)
4155 Indent only in inner namespaces (nested in other namespaces).
4166 * ``NI_All`` (in configuration: ``All``)
4167 Indent in all namespaces.
4180 .. _NamespaceMacros:
4182 **NamespaceMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <NamespaceMacros>`
4183 A vector of macros which are used to open namespace blocks.
4185 These are expected to be macros of the form:
4189 NAMESPACE(<namespace-name>, ...) {
4193 For example: TESTSUITE
4195 .. _ObjCBinPackProtocolList:
4197 **ObjCBinPackProtocolList** (``BinPackStyle``) :versionbadge:`clang-format 7` :ref:`¶ <ObjCBinPackProtocolList>`
4198 Controls bin-packing Objective-C protocol conformance list
4199 items into as few lines as possible when they go over ``ColumnLimit``.
4201 If ``Auto`` (the default), delegates to the value in
4202 ``BinPackParameters``. If that is ``true``, bin-packs Objective-C
4203 protocol conformance list items into as few lines as possible
4204 whenever they go over ``ColumnLimit``.
4206 If ``Always``, always bin-packs Objective-C protocol conformance
4207 list items into as few lines as possible whenever they go over
4210 If ``Never``, lays out Objective-C protocol conformance list items
4211 onto individual lines whenever they go over ``ColumnLimit``.
4214 .. code-block:: objc
4216 Always (or Auto, if BinPackParameters=true):
4217 @interface ccccccccccccc () <
4218 ccccccccccccc, ccccccccccccc,
4219 ccccccccccccc, ccccccccccccc> {
4222 Never (or Auto, if BinPackParameters=false):
4223 @interface ddddddddddddd () <
4232 * ``BPS_Auto`` (in configuration: ``Auto``)
4233 Automatically determine parameter bin-packing behavior.
4235 * ``BPS_Always`` (in configuration: ``Always``)
4236 Always bin-pack parameters.
4238 * ``BPS_Never`` (in configuration: ``Never``)
4239 Never bin-pack parameters.
4243 .. _ObjCBlockIndentWidth:
4245 **ObjCBlockIndentWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCBlockIndentWidth>`
4246 The number of characters to use for indentation of ObjC blocks.
4248 .. code-block:: objc
4250 ObjCBlockIndentWidth: 4
4252 [operation setCompletionBlock:^{
4253 [self onOperationDone];
4256 .. _ObjCBreakBeforeNestedBlockParam:
4258 **ObjCBreakBeforeNestedBlockParam** (``Boolean``) :versionbadge:`clang-format 11` :ref:`¶ <ObjCBreakBeforeNestedBlockParam>`
4259 Break parameters list into lines when there is nested block
4260 parameters in a function call.
4267 [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
4277 callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
4282 .. _ObjCPropertyAttributeOrder:
4284 **ObjCPropertyAttributeOrder** (``List of Strings``) :versionbadge:`clang-format 18` :ref:`¶ <ObjCPropertyAttributeOrder>`
4285 The order in which ObjC property attributes should appear.
4287 Attributes in code will be sorted in the order specified. Any attributes
4288 encountered that are not mentioned in this array will be sorted last, in
4289 stable order. Comments between attributes will leave the attributes
4294 Using this option could lead to incorrect code formatting due to
4295 clang-format's lack of complete semantic information. As such, extra
4296 care should be taken to review code changes made by this option.
4298 .. code-block:: yaml
4300 ObjCPropertyAttributeOrder: [
4303 assign, retain, strong, copy, weak, unsafe_unretained,
4304 readonly, readwrite, getter, setter,
4305 nullable, nonnull, null_resettable, null_unspecified
4308 .. _ObjCSpaceAfterProperty:
4310 **ObjCSpaceAfterProperty** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceAfterProperty>`
4311 Add a space after ``@property`` in Objective-C, i.e. use
4312 ``@property (readonly)`` instead of ``@property(readonly)``.
4314 .. _ObjCSpaceBeforeProtocolList:
4316 **ObjCSpaceBeforeProtocolList** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <ObjCSpaceBeforeProtocolList>`
4317 Add a space in front of an Objective-C protocol list, i.e. use
4318 ``Foo <Protocol>`` instead of ``Foo<Protocol>``.
4322 **PPIndentWidth** (``Integer``) :versionbadge:`clang-format 13` :ref:`¶ <PPIndentWidth>`
4323 The number of columns to use for indentation of preprocessor statements.
4324 When set to -1 (default) ``IndentWidth`` is used also for preprocessor
4337 .. _PackConstructorInitializers:
4339 **PackConstructorInitializers** (``PackConstructorInitializersStyle``) :versionbadge:`clang-format 14` :ref:`¶ <PackConstructorInitializers>`
4340 The pack constructor initializers style to use.
4344 * ``PCIS_Never`` (in configuration: ``Never``)
4345 Always put each constructor initializer on its own line.
4353 * ``PCIS_BinPack`` (in configuration: ``BinPack``)
4354 Bin-pack constructor initializers.
4359 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(),
4360 cccccccccccccccccccc()
4362 * ``PCIS_CurrentLine`` (in configuration: ``CurrentLine``)
4363 Put all constructor initializers on the current line if they fit.
4364 Otherwise, put each one on its own line.
4368 Constructor() : a(), b()
4371 : aaaaaaaaaaaaaaaaaaaa(),
4372 bbbbbbbbbbbbbbbbbbbb(),
4375 * ``PCIS_NextLine`` (in configuration: ``NextLine``)
4376 Same as ``PCIS_CurrentLine`` except that if all constructor initializers
4377 do not fit on the current line, try to fit them on the next line.
4381 Constructor() : a(), b()
4384 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), ddddddddddddd()
4387 : aaaaaaaaaaaaaaaaaaaa(),
4388 bbbbbbbbbbbbbbbbbbbb(),
4389 cccccccccccccccccccc()
4391 * ``PCIS_NextLineOnly`` (in configuration: ``NextLineOnly``)
4392 Put all constructor initializers on the next line if they fit.
4393 Otherwise, put each one on its own line.
4401 : aaaaaaaaaaaaaaaaaaaa(), bbbbbbbbbbbbbbbbbbbb(), ddddddddddddd()
4404 : aaaaaaaaaaaaaaaaaaaa(),
4405 bbbbbbbbbbbbbbbbbbbb(),
4406 cccccccccccccccccccc()
4410 .. _PenaltyBreakAssignment:
4412 **PenaltyBreakAssignment** (``Unsigned``) :versionbadge:`clang-format 5` :ref:`¶ <PenaltyBreakAssignment>`
4413 The penalty for breaking around an assignment operator.
4415 .. _PenaltyBreakBeforeFirstCallParameter:
4417 **PenaltyBreakBeforeFirstCallParameter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakBeforeFirstCallParameter>`
4418 The penalty for breaking a function call after ``call(``.
4420 .. _PenaltyBreakComment:
4422 **PenaltyBreakComment** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakComment>`
4423 The penalty for each line break introduced inside a comment.
4425 .. _PenaltyBreakFirstLessLess:
4427 **PenaltyBreakFirstLessLess** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakFirstLessLess>`
4428 The penalty for breaking before the first ``<<``.
4430 .. _PenaltyBreakOpenParenthesis:
4432 **PenaltyBreakOpenParenthesis** (``Unsigned``) :versionbadge:`clang-format 14` :ref:`¶ <PenaltyBreakOpenParenthesis>`
4433 The penalty for breaking after ``(``.
4435 .. _PenaltyBreakScopeResolution:
4437 **PenaltyBreakScopeResolution** (``Unsigned``) :versionbadge:`clang-format 18` :ref:`¶ <PenaltyBreakScopeResolution>`
4438 The penalty for breaking after ``::``.
4440 .. _PenaltyBreakString:
4442 **PenaltyBreakString** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyBreakString>`
4443 The penalty for each line break introduced inside a string literal.
4445 .. _PenaltyBreakTemplateDeclaration:
4447 **PenaltyBreakTemplateDeclaration** (``Unsigned``) :versionbadge:`clang-format 7` :ref:`¶ <PenaltyBreakTemplateDeclaration>`
4448 The penalty for breaking after template declaration.
4450 .. _PenaltyExcessCharacter:
4452 **PenaltyExcessCharacter** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyExcessCharacter>`
4453 The penalty for each character outside of the column limit.
4455 .. _PenaltyIndentedWhitespace:
4457 **PenaltyIndentedWhitespace** (``Unsigned``) :versionbadge:`clang-format 12` :ref:`¶ <PenaltyIndentedWhitespace>`
4458 Penalty for each character of whitespace indentation
4459 (counted relative to leading non-whitespace column).
4461 .. _PenaltyReturnTypeOnItsOwnLine:
4463 **PenaltyReturnTypeOnItsOwnLine** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <PenaltyReturnTypeOnItsOwnLine>`
4464 Penalty for putting the return type of a function onto its own line.
4466 .. _PointerAlignment:
4468 **PointerAlignment** (``PointerAlignmentStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <PointerAlignment>`
4469 Pointer and reference alignment style.
4473 * ``PAS_Left`` (in configuration: ``Left``)
4474 Align pointer to the left.
4480 * ``PAS_Right`` (in configuration: ``Right``)
4481 Align pointer to the right.
4487 * ``PAS_Middle`` (in configuration: ``Middle``)
4488 Align pointer in the middle.
4496 .. _QualifierAlignment:
4498 **QualifierAlignment** (``QualifierAlignmentStyle``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierAlignment>`
4499 Different ways to arrange specifiers and qualifiers (e.g. const/volatile).
4503 Setting ``QualifierAlignment`` to something other than ``Leave``, COULD
4504 lead to incorrect code formatting due to incorrect decisions made due to
4505 clang-formats lack of complete semantic information.
4506 As such extra care should be taken to review code changes made by the use
4511 * ``QAS_Leave`` (in configuration: ``Leave``)
4512 Don't change specifiers/qualifiers to either Left or Right alignment
4520 * ``QAS_Left`` (in configuration: ``Left``)
4521 Change specifiers/qualifiers to be left-aligned.
4528 * ``QAS_Right`` (in configuration: ``Right``)
4529 Change specifiers/qualifiers to be right-aligned.
4536 * ``QAS_Custom`` (in configuration: ``Custom``)
4537 Change specifiers/qualifiers to be aligned based on ``QualifierOrder``.
4540 .. code-block:: yaml
4542 QualifierOrder: ['inline', 'static', 'type', 'const']
4555 **QualifierOrder** (``List of Strings``) :versionbadge:`clang-format 14` :ref:`¶ <QualifierOrder>`
4556 The order in which the qualifiers appear.
4557 Order is an array that can contain any of the following:
4571 it MUST contain 'type'.
4573 Items to the left of 'type' will be placed to the left of the type and
4574 aligned in the order supplied. Items to the right of 'type' will be
4575 placed to the right of the type and aligned in the order supplied.
4578 .. code-block:: yaml
4580 QualifierOrder: ['inline', 'static', 'type', 'const', 'volatile' ]
4582 .. _RawStringFormats:
4584 **RawStringFormats** (``List of RawStringFormats``) :versionbadge:`clang-format 6` :ref:`¶ <RawStringFormats>`
4585 Defines hints for detecting supported languages code blocks in raw
4588 A raw string with a matching delimiter or a matching enclosing function
4589 name will be reformatted assuming the specified language based on the
4590 style for that language defined in the .clang-format file. If no style has
4591 been defined in the .clang-format file for the specific language, a
4592 predefined style given by 'BasedOnStyle' is used. If 'BasedOnStyle' is not
4593 found, the formatting is based on llvm style. A matching delimiter takes
4594 precedence over a matching enclosing function name for determining the
4595 language of the raw string contents.
4597 If a canonical delimiter is specified, occurrences of other delimiters for
4598 the same language will be updated to the canonical if possible.
4600 There should be at most one specification per language and each delimiter
4601 and enclosing function should not occur in multiple specifications.
4603 To configure this in the .clang-format file, use:
4605 .. code-block:: yaml
4608 - Language: TextProto
4613 - 'PARSE_TEXT_PROTO'
4614 BasedOnStyle: google
4620 CanonicalDelimiter: 'cc'
4622 .. _ReferenceAlignment:
4624 **ReferenceAlignment** (``ReferenceAlignmentStyle``) :versionbadge:`clang-format 13` :ref:`¶ <ReferenceAlignment>`
4625 Reference alignment style (overrides ``PointerAlignment`` for
4630 * ``RAS_Pointer`` (in configuration: ``Pointer``)
4631 Align reference like ``PointerAlignment``.
4633 * ``RAS_Left`` (in configuration: ``Left``)
4634 Align reference to the left.
4640 * ``RAS_Right`` (in configuration: ``Right``)
4641 Align reference to the right.
4647 * ``RAS_Middle`` (in configuration: ``Middle``)
4648 Align reference in the middle.
4658 **ReflowComments** (``Boolean``) :versionbadge:`clang-format 3.8` :ref:`¶ <ReflowComments>`
4659 If ``true``, clang-format will attempt to re-flow comments. That is it
4660 will touch a comment and *reflow* long comments into new lines, trying to
4661 obey the ``ColumnLimit``.
4666 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
4667 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information */
4670 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
4672 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
4675 .. _RemoveBracesLLVM:
4677 **RemoveBracesLLVM** (``Boolean``) :versionbadge:`clang-format 14` :ref:`¶ <RemoveBracesLLVM>`
4678 Remove optional braces of control statements (``if``, ``else``, ``for``,
4679 and ``while``) in C++ according to the LLVM coding style.
4683 This option will be renamed and expanded to support other styles.
4687 Setting this option to ``true`` could lead to incorrect code formatting
4688 due to clang-format's lack of complete semantic information. As such,
4689 extra care should be taken to review code changes made by this option.
4695 if (isa<FunctionDecl>(D)) { vs. if (isa<FunctionDecl>(D))
4696 handleFunctionDecl(D); handleFunctionDecl(D);
4697 } else if (isa<VarDecl>(D)) { else if (isa<VarDecl>(D))
4698 handleVarDecl(D); handleVarDecl(D);
4701 if (isa<VarDecl>(D)) { vs. if (isa<VarDecl>(D)) {
4702 for (auto *A : D.attrs()) { for (auto *A : D.attrs())
4703 if (shouldProcessAttr(A)) { if (shouldProcessAttr(A))
4704 handleAttr(A); handleAttr(A);
4709 if (isa<FunctionDecl>(D)) { vs. if (isa<FunctionDecl>(D))
4710 for (auto *A : D.attrs()) { for (auto *A : D.attrs())
4711 handleAttr(A); handleAttr(A);
4715 if (auto *D = (T)(D)) { vs. if (auto *D = (T)(D)) {
4716 if (shouldProcess(D)) { if (shouldProcess(D))
4717 handleVarDecl(D); handleVarDecl(D);
4719 markAsIgnored(D); markAsIgnored(D);
4725 } else { else if (c)
4733 .. _RemoveParentheses:
4735 **RemoveParentheses** (``RemoveParenthesesStyle``) :versionbadge:`clang-format 17` :ref:`¶ <RemoveParentheses>`
4736 Remove redundant parentheses.
4740 Setting this option to any value other than ``Leave`` could lead to
4741 incorrect code formatting due to clang-format's lack of complete semantic
4742 information. As such, extra care should be taken to review code changes
4743 made by this option.
4747 * ``RPS_Leave`` (in configuration: ``Leave``)
4748 Do not remove parentheses.
4752 class __declspec((dllimport)) X {};
4754 return ((a + b) - ((c + d)));
4756 * ``RPS_MultipleParentheses`` (in configuration: ``MultipleParentheses``)
4757 Replace multiple parentheses with single parentheses.
4761 class __declspec(dllimport) X {};
4763 return ((a + b) - (c + d));
4765 * ``RPS_ReturnStatement`` (in configuration: ``ReturnStatement``)
4766 Also remove parentheses enclosing the expression in a
4767 ``return``/``co_return`` statement.
4771 class __declspec(dllimport) X {};
4773 return (a + b) - (c + d);
4777 .. _RemoveSemicolon:
4779 **RemoveSemicolon** (``Boolean``) :versionbadge:`clang-format 16` :ref:`¶ <RemoveSemicolon>`
4780 Remove semicolons after the closing brace of a non-empty function.
4784 Setting this option to ``true`` could lead to incorrect code formatting
4785 due to clang-format's lack of complete semantic information. As such,
4786 extra care should be taken to review code changes made by this option.
4792 int max(int a, int b) { int max(int a, int b) {
4793 return a > b ? a : b; return a > b ? a : b;
4796 .. _RequiresClausePosition:
4798 **RequiresClausePosition** (``RequiresClausePositionStyle``) :versionbadge:`clang-format 15` :ref:`¶ <RequiresClausePosition>`
4799 The position of the ``requires`` clause.
4803 * ``RCPS_OwnLine`` (in configuration: ``OwnLine``)
4804 Always put the ``requires`` clause on its own line.
4808 template <typename T>
4812 template <typename T>
4816 template <typename T>
4821 * ``RCPS_WithPreceding`` (in configuration: ``WithPreceding``)
4822 Try to put the clause together with the preceding part of a declaration.
4823 For class templates: stick to the template declaration.
4824 For function templates: stick to the template declaration.
4825 For function declaration followed by a requires clause: stick to the
4830 template <typename T> requires C<T>
4833 template <typename T> requires C<T>
4836 template <typename T>
4837 void baz(T t) requires C<T>
4840 * ``RCPS_WithFollowing`` (in configuration: ``WithFollowing``)
4841 Try to put the ``requires`` clause together with the class or function
4846 template <typename T>
4847 requires C<T> struct Foo {...
4849 template <typename T>
4850 requires C<T> void bar(T t) {...
4852 template <typename T>
4856 * ``RCPS_SingleLine`` (in configuration: ``SingleLine``)
4857 Try to put everything in the same line if possible. Otherwise normal
4858 line breaking rules take over.
4863 template <typename T> requires C<T> struct Foo {...
4865 template <typename T> requires C<T> void bar(T t) {...
4867 template <typename T> void bar(T t) requires C<T> {...
4869 // Not fitting, one possible example:
4870 template <typename LongName>
4871 requires C<LongName>
4874 template <typename LongName>
4875 requires C<LongName>
4876 void bar(LongName ln) {
4878 template <typename LongName>
4879 void bar(LongName ln)
4880 requires C<LongName> {
4884 .. _RequiresExpressionIndentation:
4886 **RequiresExpressionIndentation** (``RequiresExpressionIndentationKind``) :versionbadge:`clang-format 16` :ref:`¶ <RequiresExpressionIndentation>`
4887 The indentation used for requires expression bodies.
4891 * ``REI_OuterScope`` (in configuration: ``OuterScope``)
4892 Align requires expression body relative to the indentation level of the
4893 outer scope the requires expression resides in.
4894 This is the default.
4898 template <typename T>
4899 concept C = requires(T t) {
4903 * ``REI_Keyword`` (in configuration: ``Keyword``)
4904 Align requires expression body relative to the ``requires`` keyword.
4908 template <typename T>
4909 concept C = requires(T t) {
4915 .. _SeparateDefinitionBlocks:
4917 **SeparateDefinitionBlocks** (``SeparateDefinitionStyle``) :versionbadge:`clang-format 14` :ref:`¶ <SeparateDefinitionBlocks>`
4918 Specifies the use of empty lines to separate definition blocks, including
4919 classes, structs, enums, and functions.
4924 #include <cstring> #include <cstring>
4926 int a, b, c; struct Foo {
4930 public: namespace Ns {
4931 struct Foobar { class Bar {
4933 int b; struct Foobar {
4941 ITEM1, int method1() {
4944 template<typename T>
4945 int method2(T x) { enum List {
4949 int method3(int par) {
4950 // ... template<typename T>
4951 } int method2(T x) {
4957 int method3(int par) {
4967 * ``SDS_Leave`` (in configuration: ``Leave``)
4968 Leave definition blocks as they are.
4970 * ``SDS_Always`` (in configuration: ``Always``)
4971 Insert an empty line between definition blocks.
4973 * ``SDS_Never`` (in configuration: ``Never``)
4974 Remove any empty line between definition blocks.
4978 .. _ShortNamespaceLines:
4980 **ShortNamespaceLines** (``Unsigned``) :versionbadge:`clang-format 13` :ref:`¶ <ShortNamespaceLines>`
4981 The maximal number of unwrapped lines that a short namespace spans.
4984 This determines the maximum length of short namespaces by counting
4985 unwrapped lines (i.e. containing neither opening nor closing
4986 namespace brace) and makes "FixNamespaceComments" omit adding
4987 end comments for those.
4991 ShortNamespaceLines: 1 vs. ShortNamespaceLines: 0
4992 namespace a { namespace a {
4996 ShortNamespaceLines: 1 vs. ShortNamespaceLines: 0
4997 namespace b { namespace b {
5000 } // namespace b } // namespace b
5004 **SortIncludes** (``SortIncludesOptions``) :versionbadge:`clang-format 3.8` :ref:`¶ <SortIncludes>`
5005 Controls if and how clang-format will sort ``#includes``.
5009 * ``SI_Never`` (in configuration: ``Never``)
5010 Includes are never sorted.
5020 * ``SI_CaseSensitive`` (in configuration: ``CaseSensitive``)
5021 Includes are sorted in an ASCIIbetical or case sensitive fashion.
5031 * ``SI_CaseInsensitive`` (in configuration: ``CaseInsensitive``)
5032 Includes are sorted in an alphabetical or case insensitive fashion.
5044 .. _SortJavaStaticImport:
5046 **SortJavaStaticImport** (``SortJavaStaticImportOptions``) :versionbadge:`clang-format 12` :ref:`¶ <SortJavaStaticImport>`
5047 When sorting Java imports, by default static imports are placed before
5048 non-static imports. If ``JavaStaticImportAfterImport`` is ``After``,
5049 static imports are placed after non-static imports.
5053 * ``SJSIO_Before`` (in configuration: ``Before``)
5054 Static imports are placed before non-static imports.
5056 .. code-block:: java
5058 import static org.example.function1;
5060 import org.example.ClassA;
5062 * ``SJSIO_After`` (in configuration: ``After``)
5063 Static imports are placed after non-static imports.
5065 .. code-block:: java
5067 import org.example.ClassA;
5069 import static org.example.function1;
5073 .. _SortUsingDeclarations:
5075 **SortUsingDeclarations** (``SortUsingDeclarationsOptions``) :versionbadge:`clang-format 5` :ref:`¶ <SortUsingDeclarations>`
5076 Controls if and how clang-format will sort using declarations.
5080 * ``SUD_Never`` (in configuration: ``Never``)
5081 Using declarations are never sorted.
5085 using std::chrono::duration_cast;
5088 using boost::regex_constants::icase;
5091 * ``SUD_Lexicographic`` (in configuration: ``Lexicographic``)
5092 Using declarations are sorted in the order defined as follows:
5093 Split the strings by "::" and discard any initial empty strings. Sort
5094 the lists of names lexicographically, and within those groups, names are
5095 in case-insensitive lexicographic order.
5100 using boost::regex_constants::icase;
5101 using std::chrono::duration_cast;
5105 * ``SUD_LexicographicNumeric`` (in configuration: ``LexicographicNumeric``)
5106 Using declarations are sorted in the order defined as follows:
5107 Split the strings by "::" and discard any initial empty strings. The
5108 last element of each list is a non-namespace name; all others are
5109 namespace names. Sort the lists of names lexicographically, where the
5110 sort order of individual names is that all non-namespace names come
5111 before all namespace names, and within those groups, names are in
5112 case-insensitive lexicographic order.
5117 using boost::regex_constants::icase;
5120 using std::chrono::duration_cast;
5124 .. _SpaceAfterCStyleCast:
5126 **SpaceAfterCStyleCast** (``Boolean``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceAfterCStyleCast>`
5127 If ``true``, a space is inserted after C style casts.
5132 (int) i; vs. (int)i;
5134 .. _SpaceAfterLogicalNot:
5136 **SpaceAfterLogicalNot** (``Boolean``) :versionbadge:`clang-format 9` :ref:`¶ <SpaceAfterLogicalNot>`
5137 If ``true``, a space is inserted after the logical not operator (``!``).
5142 ! someExpression(); vs. !someExpression();
5144 .. _SpaceAfterTemplateKeyword:
5146 **SpaceAfterTemplateKeyword** (``Boolean``) :versionbadge:`clang-format 4` :ref:`¶ <SpaceAfterTemplateKeyword>`
5147 If ``true``, a space will be inserted after the 'template' keyword.
5152 template <int> void foo(); vs. template<int> void foo();
5154 .. _SpaceAroundPointerQualifiers:
5156 **SpaceAroundPointerQualifiers** (``SpaceAroundPointerQualifiersStyle``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceAroundPointerQualifiers>`
5157 Defines in which cases to put a space before or after pointer qualifiers
5161 * ``SAPQ_Default`` (in configuration: ``Default``)
5162 Don't ensure spaces around pointer qualifiers and use PointerAlignment
5167 PointerAlignment: Left PointerAlignment: Right
5168 void* const* x = NULL; vs. void *const *x = NULL;
5170 * ``SAPQ_Before`` (in configuration: ``Before``)
5171 Ensure that there is a space before pointer qualifiers.
5175 PointerAlignment: Left PointerAlignment: Right
5176 void* const* x = NULL; vs. void * const *x = NULL;
5178 * ``SAPQ_After`` (in configuration: ``After``)
5179 Ensure that there is a space after pointer qualifiers.
5183 PointerAlignment: Left PointerAlignment: Right
5184 void* const * x = NULL; vs. void *const *x = NULL;
5186 * ``SAPQ_Both`` (in configuration: ``Both``)
5187 Ensure that there is a space both before and after pointer qualifiers.
5191 PointerAlignment: Left PointerAlignment: Right
5192 void* const * x = NULL; vs. void * const *x = NULL;
5196 .. _SpaceBeforeAssignmentOperators:
5198 **SpaceBeforeAssignmentOperators** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceBeforeAssignmentOperators>`
5199 If ``false``, spaces will be removed before assignment operators.
5204 int a = 5; vs. int a= 5;
5207 .. _SpaceBeforeCaseColon:
5209 **SpaceBeforeCaseColon** (``Boolean``) :versionbadge:`clang-format 12` :ref:`¶ <SpaceBeforeCaseColon>`
5210 If ``false``, spaces will be removed before case colon.
5215 switch (x) { vs. switch (x) {
5216 case 1 : break; case 1: break;
5219 .. _SpaceBeforeCpp11BracedList:
5221 **SpaceBeforeCpp11BracedList** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCpp11BracedList>`
5222 If ``true``, a space will be inserted before a C++11 braced list
5223 used to initialize an object (after the preceding identifier or type).
5228 Foo foo { bar }; vs. Foo foo{ bar };
5230 vector<int> { 1, 2, 3 }; vector<int>{ 1, 2, 3 };
5231 new int[3] { 1, 2, 3 }; new int[3]{ 1, 2, 3 };
5233 .. _SpaceBeforeCtorInitializerColon:
5235 **SpaceBeforeCtorInitializerColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeCtorInitializerColon>`
5236 If ``false``, spaces will be removed before constructor initializer
5242 Foo::Foo() : a(a) {} Foo::Foo(): a(a) {}
5244 .. _SpaceBeforeInheritanceColon:
5246 **SpaceBeforeInheritanceColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeInheritanceColon>`
5247 If ``false``, spaces will be removed before inheritance colon.
5252 class Foo : Bar {} vs. class Foo: Bar {}
5254 .. _SpaceBeforeJsonColon:
5256 **SpaceBeforeJsonColon** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <SpaceBeforeJsonColon>`
5257 If ``true``, a space will be added before a JSON colon. For other
5258 languages, e.g. JavaScript, use ``SpacesInContainerLiterals`` instead.
5264 "key" : "value" vs. "key": "value"
5267 .. _SpaceBeforeParens:
5269 **SpaceBeforeParens** (``SpaceBeforeParensStyle``) :versionbadge:`clang-format 3.5` :ref:`¶ <SpaceBeforeParens>`
5270 Defines in which cases to put a space before opening parentheses.
5274 * ``SBPO_Never`` (in configuration: ``Never``)
5275 Never put a space before opening parentheses.
5285 * ``SBPO_ControlStatements`` (in configuration: ``ControlStatements``)
5286 Put a space before opening parentheses only after control statement
5287 keywords (``for/if/while...``).
5297 * ``SBPO_ControlStatementsExceptControlMacros`` (in configuration: ``ControlStatementsExceptControlMacros``)
5298 Same as ``SBPO_ControlStatements`` except this option doesn't apply to
5299 ForEach and If macros. This is useful in projects where ForEach/If
5300 macros are treated as function calls instead of control statements.
5301 ``SBPO_ControlStatementsExceptForEachMacros`` remains an alias for
5302 backward compatibility.
5312 * ``SBPO_NonEmptyParentheses`` (in configuration: ``NonEmptyParentheses``)
5313 Put a space before opening parentheses only if the parentheses are not
5325 * ``SBPO_Always`` (in configuration: ``Always``)
5326 Always put a space before opening parentheses, except when it's
5327 prohibited by the syntax rules (in function-like macro definitions) or
5328 when determined by other style rules (after unary operators, opening
5339 * ``SBPO_Custom`` (in configuration: ``Custom``)
5340 Configure each individual space before parentheses in
5341 ``SpaceBeforeParensOptions``.
5345 .. _SpaceBeforeParensOptions:
5347 **SpaceBeforeParensOptions** (``SpaceBeforeParensCustom``) :versionbadge:`clang-format 14` :ref:`¶ <SpaceBeforeParensOptions>`
5348 Control of individual space before parentheses.
5350 If ``SpaceBeforeParens`` is set to ``Custom``, use this to specify
5351 how each individual space before parentheses case should be handled.
5352 Otherwise, this is ignored.
5354 .. code-block:: yaml
5357 SpaceBeforeParens: Custom
5358 SpaceBeforeParensOptions:
5359 AfterControlStatements: true
5360 AfterFunctionDefinitionName: true
5362 Nested configuration flags:
5364 Precise control over the spacing before parentheses.
5368 # Should be declared this way:
5369 SpaceBeforeParens: Custom
5370 SpaceBeforeParensOptions:
5371 AfterControlStatements: true
5372 AfterFunctionDefinitionName: true
5374 * ``bool AfterControlStatements`` If ``true``, put space between control statement keywords
5375 (for/if/while...) and opening parentheses.
5380 if (...) {} vs. if(...) {}
5382 * ``bool AfterForeachMacros`` If ``true``, put space between foreach macros and opening parentheses.
5387 FOREACH (...) vs. FOREACH(...)
5388 <loop-body> <loop-body>
5390 * ``bool AfterFunctionDeclarationName`` If ``true``, put a space between function declaration name and opening
5396 void f (); vs. void f();
5398 * ``bool AfterFunctionDefinitionName`` If ``true``, put a space between function definition name and opening
5404 void f () {} vs. void f() {}
5406 * ``bool AfterIfMacros`` If ``true``, put space between if macros and opening parentheses.
5411 IF (...) vs. IF(...)
5412 <conditional-body> <conditional-body>
5414 * ``bool AfterOverloadedOperator`` If ``true``, put a space between operator overloading and opening
5420 void operator++ (int a); vs. void operator++(int a);
5421 object.operator++ (10); object.operator++(10);
5423 * ``AfterPlacementOperatorStyle AfterPlacementOperator`` :versionbadge:`clang-format 18`
5425 Defines in which cases to put a space between ``new/delete`` operators
5426 and opening parentheses.
5430 * ``APO_Never`` (in configuration: ``Never``)
5431 Remove space after ``new/delete`` operators and before ``(``.
5438 * ``APO_Always`` (in configuration: ``Always``)
5439 Always add space after ``new/delete`` operators and before ``(``.
5446 * ``APO_Leave`` (in configuration: ``Leave``)
5447 Leave placement ``new/delete`` expressions as they are.
5450 * ``bool AfterRequiresInClause`` If ``true``, put space between requires keyword in a requires clause and
5451 opening parentheses, if there is one.
5456 template<typename T> vs. template<typename T>
5457 requires (A<T> && B<T>) requires(A<T> && B<T>)
5460 * ``bool AfterRequiresInExpression`` If ``true``, put space between requires keyword in a requires expression
5461 and opening parentheses.
5466 template<typename T> vs. template<typename T>
5467 concept C = requires (T t) { concept C = requires(T t) {
5471 * ``bool BeforeNonEmptyParentheses`` If ``true``, put a space before opening parentheses only if the
5472 parentheses are not empty.
5477 void f (int a); vs. void f();
5481 .. _SpaceBeforeRangeBasedForLoopColon:
5483 **SpaceBeforeRangeBasedForLoopColon** (``Boolean``) :versionbadge:`clang-format 7` :ref:`¶ <SpaceBeforeRangeBasedForLoopColon>`
5484 If ``false``, spaces will be removed before range-based for loop
5490 for (auto v : values) {} vs. for(auto v: values) {}
5492 .. _SpaceBeforeSquareBrackets:
5494 **SpaceBeforeSquareBrackets** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceBeforeSquareBrackets>`
5495 If ``true``, spaces will be before ``[``.
5496 Lambdas will not be affected. Only the first ``[`` will get a space added.
5501 int a [5]; vs. int a[5];
5502 int a [5][5]; vs. int a[5][5];
5504 .. _SpaceInEmptyBlock:
5506 **SpaceInEmptyBlock** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpaceInEmptyBlock>`
5507 If ``true``, spaces will be inserted into ``{}``.
5512 void f() { } vs. void f() {}
5513 while (true) { } while (true) {}
5515 .. _SpaceInEmptyParentheses:
5517 **SpaceInEmptyParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpaceInEmptyParentheses>`
5518 If ``true``, spaces may be inserted into ``()``.
5519 This option is **deprecated**. See ``InEmptyParentheses`` of
5520 ``SpacesInParensOptions``.
5522 .. _SpacesBeforeTrailingComments:
5524 **SpacesBeforeTrailingComments** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesBeforeTrailingComments>`
5525 The number of spaces before trailing line comments
5526 (``//`` - comments).
5528 This does not affect trailing block comments (``/*`` - comments) as those
5529 commonly have different usage patterns and a number of special cases. In
5530 the case of Verilog, it doesn't affect a comment right after the opening
5531 parenthesis in the port or parameter list in a module header, because it
5532 is probably for the port on the following line instead of the parenthesis
5537 SpacesBeforeTrailingComments: 3
5546 **SpacesInAngles** (``SpacesInAnglesStyle``) :versionbadge:`clang-format 3.4` :ref:`¶ <SpacesInAngles>`
5547 The SpacesInAnglesStyle to use for template argument lists.
5551 * ``SIAS_Never`` (in configuration: ``Never``)
5552 Remove spaces after ``<`` and before ``>``.
5556 static_cast<int>(arg);
5557 std::function<void(int)> fct;
5559 * ``SIAS_Always`` (in configuration: ``Always``)
5560 Add spaces after ``<`` and before ``>``.
5564 static_cast< int >(arg);
5565 std::function< void(int) > fct;
5567 * ``SIAS_Leave`` (in configuration: ``Leave``)
5568 Keep a single space after ``<`` and before ``>`` if any spaces were
5569 present. Option ``Standard: Cpp03`` takes precedence.
5573 .. _SpacesInCStyleCastParentheses:
5575 **SpacesInCStyleCastParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInCStyleCastParentheses>`
5576 If ``true``, spaces may be inserted into C style casts.
5577 This option is **deprecated**. See ``InCStyleCasts`` of
5578 ``SpacesInParensOptions``.
5580 .. _SpacesInConditionalStatement:
5582 **SpacesInConditionalStatement** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <SpacesInConditionalStatement>`
5583 If ``true``, spaces will be inserted around if/for/switch/while
5585 This option is **deprecated**. See ``InConditionalStatements`` of
5586 ``SpacesInParensOptions``.
5588 .. _SpacesInContainerLiterals:
5590 **SpacesInContainerLiterals** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInContainerLiterals>`
5591 If ``true``, spaces are inserted inside container literals (e.g. ObjC and
5592 Javascript array and dict literals). For JSON, use
5593 ``SpaceBeforeJsonColon`` instead.
5598 var arr = [ 1, 2, 3 ]; vs. var arr = [1, 2, 3];
5599 f({a : 1, b : 2, c : 3}); f({a: 1, b: 2, c: 3});
5601 .. _SpacesInLineCommentPrefix:
5603 **SpacesInLineCommentPrefix** (``SpacesInLineComment``) :versionbadge:`clang-format 13` :ref:`¶ <SpacesInLineCommentPrefix>`
5604 How many spaces are allowed at the start of a line comment. To disable the
5605 maximum set it to ``-1``, apart from that the maximum takes precedence
5612 // One space is forced
5614 // but more spaces are possible
5618 //Forces to start every comment directly after the slashes
5620 Note that in line comment sections the relative indent of the subsequent
5621 lines is kept, that means the following:
5627 //if (b) { // if (b) {
5628 // return true; // return true;
5636 This option has only effect if ``ReflowComments`` is set to ``true``.
5638 Nested configuration flags:
5640 Control of spaces within a single line comment.
5642 * ``unsigned Minimum`` The minimum number of spaces at the start of the comment.
5644 * ``unsigned Maximum`` The maximum number of spaces at the start of the comment.
5649 **SpacesInParens** (``SpacesInParensStyle``) :versionbadge:`clang-format 17` :ref:`¶ <SpacesInParens>`
5650 Defines in which cases spaces will be inserted after ``(`` and before
5655 * ``SIPO_Never`` (in configuration: ``Never``)
5656 Never put a space in parentheses.
5666 * ``SIPO_Custom`` (in configuration: ``Custom``)
5667 Configure each individual space in parentheses in
5668 `SpacesInParensOptions`.
5672 .. _SpacesInParensOptions:
5674 **SpacesInParensOptions** (``SpacesInParensCustom``) :versionbadge:`clang-format 17` :ref:`¶ <SpacesInParensOptions>`
5675 Control of individual spaces in parentheses.
5677 If ``SpacesInParens`` is set to ``Custom``, use this to specify
5678 how each individual space in parentheses case should be handled.
5679 Otherwise, this is ignored.
5681 .. code-block:: yaml
5684 SpacesInParens: Custom
5685 SpacesInParensOptions:
5686 InConditionalStatements: true
5687 InEmptyParentheses: true
5689 Nested configuration flags:
5691 Precise control over the spacing in parentheses.
5695 # Should be declared this way:
5696 SpacesInParens: Custom
5697 SpacesInParensOptions:
5698 InConditionalStatements: true
5701 * ``bool InConditionalStatements`` Put a space in parentheses only inside conditional statements
5702 (``for/if/while/switch...``).
5707 if ( a ) { ... } vs. if (a) { ... }
5708 while ( i < 5 ) { ... } while (i < 5) { ... }
5710 * ``bool InCStyleCasts`` Put a space in C style casts.
5715 x = ( int32 )y vs. x = (int32)y
5717 * ``bool InEmptyParentheses`` Put a space in parentheses only if the parentheses are empty i.e. '()'
5722 void f( ) { vs. void f() {
5723 int x[] = {foo( ), bar( )}; int x[] = {foo(), bar()};
5724 if (true) { if (true) {
5729 * ``bool Other`` Put a space in parentheses not covered by preceding options.
5734 t f( Deleted & ) & = delete; vs. t f(Deleted &) & = delete;
5737 .. _SpacesInParentheses:
5739 **SpacesInParentheses** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInParentheses>`
5740 If ``true``, spaces will be inserted after ``(`` and before ``)``.
5741 This option is **deprecated**. The previous behavior is preserved by using
5742 ``SpacesInParens`` with ``Custom`` and by setting all
5743 ``SpacesInParensOptions`` to ``true`` except for ``InCStyleCasts`` and
5744 ``InEmptyParentheses``.
5746 .. _SpacesInSquareBrackets:
5748 **SpacesInSquareBrackets** (``Boolean``) :versionbadge:`clang-format 3.7` :ref:`¶ <SpacesInSquareBrackets>`
5749 If ``true``, spaces will be inserted after ``[`` and before ``]``.
5750 Lambdas without arguments or unspecified size array declarations will not
5756 int a[ 5 ]; vs. int a[5];
5757 std::unique_ptr<int[]> foo() {} // Won't be affected
5761 **Standard** (``LanguageStandard``) :versionbadge:`clang-format 3.7` :ref:`¶ <Standard>`
5762 Parse and format C++ constructs compatible with this standard.
5767 vector<set<int> > x; vs. vector<set<int>> x;
5771 * ``LS_Cpp03`` (in configuration: ``c++03``)
5772 Parse and format as C++03.
5773 ``Cpp03`` is a deprecated alias for ``c++03``
5775 * ``LS_Cpp11`` (in configuration: ``c++11``)
5776 Parse and format as C++11.
5778 * ``LS_Cpp14`` (in configuration: ``c++14``)
5779 Parse and format as C++14.
5781 * ``LS_Cpp17`` (in configuration: ``c++17``)
5782 Parse and format as C++17.
5784 * ``LS_Cpp20`` (in configuration: ``c++20``)
5785 Parse and format as C++20.
5787 * ``LS_Latest`` (in configuration: ``Latest``)
5788 Parse and format using the latest supported language version.
5789 ``Cpp11`` is a deprecated alias for ``Latest``
5791 * ``LS_Auto`` (in configuration: ``Auto``)
5792 Automatic detection based on the input.
5796 .. _StatementAttributeLikeMacros:
5798 **StatementAttributeLikeMacros** (``List of Strings``) :versionbadge:`clang-format 12` :ref:`¶ <StatementAttributeLikeMacros>`
5799 Macros which are ignored in front of a statement, as if they were an
5800 attribute. So that they are not parsed as identifier, for example for Qts
5805 AlignConsecutiveDeclarations: true
5806 StatementAttributeLikeMacros: []
5807 unsigned char data = 'x';
5808 emit signal(data); // This is parsed as variable declaration.
5810 AlignConsecutiveDeclarations: true
5811 StatementAttributeLikeMacros: [emit]
5812 unsigned char data = 'x';
5813 emit signal(data); // Now it's fine again.
5815 .. _StatementMacros:
5817 **StatementMacros** (``List of Strings``) :versionbadge:`clang-format 8` :ref:`¶ <StatementMacros>`
5818 A vector of macros that should be interpreted as complete
5821 Typical macros are expressions, and require a semi-colon to be
5822 added; sometimes this is not the case, and this allows to make
5823 clang-format aware of such cases.
5825 For example: Q_UNUSED
5829 **TabWidth** (``Unsigned``) :versionbadge:`clang-format 3.7` :ref:`¶ <TabWidth>`
5830 The number of columns used for tab stops.
5834 **TypeNames** (``List of Strings``) :versionbadge:`clang-format 17` :ref:`¶ <TypeNames>`
5835 A vector of non-keyword identifiers that should be interpreted as type
5838 A ``*``, ``&``, or ``&&`` between a type name and another non-keyword
5839 identifier is annotated as a pointer or reference token instead of a
5844 **TypenameMacros** (``List of Strings``) :versionbadge:`clang-format 9` :ref:`¶ <TypenameMacros>`
5845 A vector of macros that should be interpreted as type declarations
5846 instead of as function calls.
5848 These are expected to be macros of the form:
5854 In the .clang-format configuration file, this can be configured like:
5856 .. code-block:: yaml
5858 TypenameMacros: ['STACK_OF', 'LIST']
5860 For example: OpenSSL STACK_OF, BSD LIST_ENTRY.
5864 **UseCRLF** (``Boolean``) :versionbadge:`clang-format 10` :ref:`¶ <UseCRLF>`
5865 This option is **deprecated**. See ``LF`` and ``CRLF`` of ``LineEnding``.
5869 **UseTab** (``UseTabStyle``) :versionbadge:`clang-format 3.7` :ref:`¶ <UseTab>`
5870 The way to use tab characters in the resulting file.
5874 * ``UT_Never`` (in configuration: ``Never``)
5877 * ``UT_ForIndentation`` (in configuration: ``ForIndentation``)
5878 Use tabs only for indentation.
5880 * ``UT_ForContinuationAndIndentation`` (in configuration: ``ForContinuationAndIndentation``)
5881 Fill all leading whitespace with tabs, and use spaces for alignment that
5882 appears within a line (e.g. consecutive assignments and declarations).
5884 * ``UT_AlignWithSpaces`` (in configuration: ``AlignWithSpaces``)
5885 Use tabs for line continuation and indentation, and spaces for
5888 * ``UT_Always`` (in configuration: ``Always``)
5889 Use tabs whenever we need to fill whitespace that spans at least from
5890 one tab stop to the next one.
5894 .. _VerilogBreakBetweenInstancePorts:
5896 **VerilogBreakBetweenInstancePorts** (``Boolean``) :versionbadge:`clang-format 17` :ref:`¶ <VerilogBreakBetweenInstancePorts>`
5897 For Verilog, put each port on its own line in module instantiations.
5908 ffnand ff1(.q(), .qbar(out1), .clear(in1), .preset(in2));
5910 .. _WhitespaceSensitiveMacros:
5912 **WhitespaceSensitiveMacros** (``List of Strings``) :versionbadge:`clang-format 11` :ref:`¶ <WhitespaceSensitiveMacros>`
5913 A vector of macros which are whitespace-sensitive and should not
5916 These are expected to be macros of the form:
5922 In the .clang-format configuration file, this can be configured like:
5924 .. code-block:: yaml
5926 WhitespaceSensitiveMacros: ['STRINGIZE', 'PP_STRINGIZE']
5928 For example: BOOST_PP_STRINGIZE
5930 .. END_FORMAT_STYLE_OPTIONS
5932 Adding additional style options
5933 ===============================
5935 Each additional style option adds costs to the clang-format project. Some of
5936 these costs affect the clang-format development itself, as we need to make
5937 sure that any given combination of options work and that new features don't
5938 break any of the existing options in any way. There are also costs for end users
5939 as options become less discoverable and people have to think about and make a
5940 decision on options they don't really care about.
5942 The goal of the clang-format project is more on the side of supporting a
5943 limited set of styles really well as opposed to supporting every single style
5944 used by a codebase somewhere in the wild. Of course, we do want to support all
5945 major projects and thus have established the following bar for adding style
5946 options. Each new style option must ..
5948 * be used in a project of significant size (have dozens of contributors)
5949 * have a publicly accessible style guide
5950 * have a person willing to contribute and maintain patches
5955 A style similar to the `Linux Kernel style
5956 <https://www.kernel.org/doc/html/latest/process/coding-style.html>`_:
5958 .. code-block:: yaml
5963 BreakBeforeBraces: Linux
5964 AllowShortIfStatementsOnASingleLine: false
5965 IndentCaseLabels: false
5967 The result is (imagine that tabs are used for indentation here):
5979 do_something_else();
5985 do_something_completely_different();
5996 A style similar to the default Visual Studio formatting style:
5998 .. code-block:: yaml
6002 BreakBeforeBraces: Allman
6003 AllowShortIfStatementsOnASingleLine: false
6004 IndentCaseLabels: false
6020 do_something_else();
6026 do_something_completely_different();