1 ==========================
2 Clang-Format Style Options
3 ==========================
5 :doc:`ClangFormatStyleOptions` describes configurable formatting style options
6 supported by :doc:`LibFormat` and :doc:`ClangFormat`.
8 When using :program:`clang-format` command line utility or
9 ``clang::format::reformat(...)`` functions from code, one can either use one of
10 the predefined styles (LLVM, Google, Chromium, Mozilla, WebKit, Microsoft) or
11 create a custom style by configuring specific style options.
14 Configuring Style with clang-format
15 ===================================
17 :program:`clang-format` supports two ways to provide custom style options:
18 directly specify style configuration in the ``-style=`` command line option or
19 use ``-style=file`` and put style configuration in the ``.clang-format`` or
20 ``_clang-format`` file in the project directory.
22 When using ``-style=file``, :program:`clang-format` for each input file will
23 try to find the ``.clang-format`` file located in the closest parent directory
24 of the input file. When the standard input is used, the search is started from
25 the current directory.
27 The ``.clang-format`` file uses YAML format:
36 The configuration file can consist of several sections each having different
37 ``Language:`` parameter denoting the programming language this section of the
38 configuration is targeted at. See the description of the **Language** option
39 below for the list of supported languages. The first section may have no
40 language set, it will set the default style options for all lanugages.
41 Configuration sections for specific language will override options set in the
44 When :program:`clang-format` formats a file, it auto-detects the language using
45 the file name. When formatting standard input or a file that doesn't have the
46 extension corresponding to its language, ``-assume-filename=`` option can be
47 used to override the file name :program:`clang-format` uses to detect the
50 An example of a configuration file for multiple languages:
55 # We'll use defaults from the LLVM style, but with 4 columns indentation.
60 # Force pointers to the type for C++.
61 DerivePointerAlignment: false
62 PointerAlignment: Left
65 # Use 100 columns for JS.
69 # Don't format .proto files.
73 # Use 100 columns for C#.
77 An easy way to get a valid ``.clang-format`` file containing all configuration
78 options of a certain predefined style is:
80 .. code-block:: console
82 clang-format -style=llvm -dump-config > .clang-format
84 When specifying configuration in the ``-style=`` option, the same configuration
85 is applied for all input files. The format of the configuration is:
87 .. code-block:: console
89 -style='{key1: value1, key2: value2, ...}'
92 Disabling Formatting on a Piece of Code
93 =======================================
95 Clang-format understands also special comments that switch formatting in a
96 delimited range. The code between a comment ``// clang-format off`` or
97 ``/* clang-format off */`` up to a comment ``// clang-format on`` or
98 ``/* clang-format on */`` will not be formatted. The comments themselves
99 will be formatted (aligned) normally.
105 void unformatted_code ;
107 void formatted_code_again;
110 Configuring Style in Code
111 =========================
113 When using ``clang::format::reformat(...)`` functions, the format is specified
114 by supplying the `clang::format::FormatStyle
115 <https://clang.llvm.org/doxygen/structclang_1_1format_1_1FormatStyle.html>`_
119 Configurable Format Style Options
120 =================================
122 This section lists the supported style options. Value type is specified for
123 each option. For enumeration types possible values are specified both as a C++
124 enumeration member (with a prefix, e.g. ``LS_Auto``), and as a value usable in
125 the configuration (without a prefix: ``Auto``).
128 **BasedOnStyle** (``string``)
129 The style used for all options not specifically set in the configuration.
131 This option is supported only in the :program:`clang-format` configuration
132 (both within ``-style='{...}'`` and the ``.clang-format`` file).
137 A style complying with the `LLVM coding standards
138 <https://llvm.org/docs/CodingStandards.html>`_
140 A style complying with `Google's C++ style guide
141 <https://google.github.io/styleguide/cppguide.html>`_
143 A style complying with `Chromium's style guide
144 <https://chromium.googlesource.com/chromium/src/+/master/styleguide/styleguide.md>`_
146 A style complying with `Mozilla's style guide
147 <https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style>`_
149 A style complying with `WebKit's style guide
150 <https://www.webkit.org/coding/coding-style.html>`_
152 A style complying with `Microsoft's style guide
153 <https://docs.microsoft.com/en-us/visualstudio/ide/editorconfig-code-style-settings-reference?view=vs-2017>`_
155 A style complying with the `GNU coding standards
156 <https://www.gnu.org/prep/standards/standards.html>`_
158 .. START_FORMAT_STYLE_OPTIONS
160 **AccessModifierOffset** (``int``)
161 The extra indent or outdent of access modifiers, e.g. ``public:``.
163 **AlignAfterOpenBracket** (``BracketAlignmentStyle``)
164 If ``true``, horizontally aligns arguments after an open bracket.
166 This applies to round brackets (parentheses), angle brackets and square
171 * ``BAS_Align`` (in configuration: ``Align``)
172 Align parameters on the open bracket, e.g.:
176 someLongFunction(argument1,
179 * ``BAS_DontAlign`` (in configuration: ``DontAlign``)
180 Don't align, instead use ``ContinuationIndentWidth``, e.g.:
184 someLongFunction(argument1,
187 * ``BAS_AlwaysBreak`` (in configuration: ``AlwaysBreak``)
188 Always break after an open bracket, if the parameters don't fit
189 on a single line, e.g.:
194 argument1, argument2);
198 **AlignConsecutiveAssignments** (``bool``)
199 If ``true``, aligns consecutive assignments.
201 This will align the assignment operators of consecutive lines. This
202 will result in formattings like
210 **AlignConsecutiveBitFields** (``bool``)
211 If ``true``, aligns consecutive bitfield members.
213 This will align the bitfield separators of consecutive lines. This
214 will result in formattings like
222 **AlignConsecutiveDeclarations** (``bool``)
223 If ``true``, aligns consecutive declarations.
225 This will align the declaration names of consecutive lines. This
226 will result in formattings like
232 std::string ccc = 23;
234 **AlignConsecutiveMacros** (``bool``)
235 If ``true``, aligns consecutive C/C++ preprocessor macros.
237 This will align C/C++ preprocessor macros of consecutive lines.
238 Will result in formattings like
242 #define SHORT_NAME 42
243 #define LONGER_NAME 0x007f
244 #define EVEN_LONGER_NAME (2)
245 #define foo(x) (x * x)
246 #define bar(y, z) (y + z)
248 **AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``)
249 Options for aligning backslashes in escaped newlines.
253 * ``ENAS_DontAlign`` (in configuration: ``DontAlign``)
254 Don't align escaped newlines.
263 * ``ENAS_Left`` (in configuration: ``Left``)
264 Align escaped newlines as far left as possible.
276 * ``ENAS_Right`` (in configuration: ``Right``)
277 Align escaped newlines in the right-most column.
288 **AlignOperands** (``OperandAlignmentStyle``)
289 If ``true``, horizontally align operands of binary and ternary
294 * ``OAS_DontAlign`` (in configuration: ``DontAlign``)
295 Do not align operands of binary and ternary expressions.
296 The wrapped lines are indented ``ContinuationIndentWidth`` spaces from
297 the start of the line.
299 * ``OAS_Align`` (in configuration: ``Align``)
300 Horizontally align operands of binary and ternary expressions.
302 Specifically, this aligns operands of a single expression that needs
303 to be split over multiple lines, e.g.:
307 int aaa = bbbbbbbbbbbbbbb +
310 When ``BreakBeforeBinaryOperators`` is set, the wrapped operator is
311 aligned with the operand on the first line.
315 int aaa = bbbbbbbbbbbbbbb
318 * ``OAS_AlignAfterOperator`` (in configuration: ``AlignAfterOperator``)
319 Horizontally align operands of binary and ternary expressions.
321 This is similar to ``AO_Align``, except when
322 ``BreakBeforeBinaryOperators`` is set, the operator is un-indented so
323 that the wrapped operand is aligned with the operand on the first line.
327 int aaa = bbbbbbbbbbbbbbb
332 **AlignTrailingComments** (``bool``)
333 If ``true``, aligns trailing comments.
338 int a; // My comment a vs. int a; // My comment a
339 int b = 2; // comment b int b = 2; // comment about b
341 **AllowAllArgumentsOnNextLine** (``bool``)
342 If a function call or braced initializer list doesn't fit on a
343 line, allow putting all arguments onto the next line, even if
344 ``BinPackArguments`` is ``false``.
358 **AllowAllConstructorInitializersOnNextLine** (``bool``)
359 If a constructor definition with a member initializer list doesn't
360 fit on a single line, allow putting all member initializers onto the next
361 line, if ```ConstructorInitializerAllOnOneLineOrOnePerLine``` is true.
362 Note that this parameter has no effect if
363 ```ConstructorInitializerAllOnOneLineOrOnePerLine``` is false.
369 member0(0), member1(2) {}
376 **AllowAllParametersOfDeclarationOnNextLine** (``bool``)
377 If the function declaration doesn't fit on a line,
378 allow putting all parameters of a function declaration onto
379 the next line even if ``BinPackParameters`` is ``false``.
385 int a, int b, int c, int d, int e);
388 void myFunction(int a,
394 **AllowShortBlocksOnASingleLine** (``ShortBlockStyle``)
395 Dependent on the value, ``while (true) { continue; }`` can be put on a
400 * ``SBS_Never`` (in configuration: ``Never``)
401 Never merge blocks into a single line.
411 * ``SBS_Empty`` (in configuration: ``Empty``)
412 Only merge empty blocks.
421 * ``SBS_Always`` (in configuration: ``Always``)
422 Always merge short blocks into a single line.
427 while (true) { continue; }
431 **AllowShortCaseLabelsOnASingleLine** (``bool``)
432 If ``true``, short case labels will be contracted to a single line.
437 switch (a) { vs. switch (a) {
438 case 1: x = 1; break; case 1:
439 case 2: return; x = 1;
445 **AllowShortEnumsOnASingleLine** (``bool``)
446 Allow short enums on a single line.
451 enum { A, B } myEnum;
460 **AllowShortFunctionsOnASingleLine** (``ShortFunctionStyle``)
461 Dependent on the value, ``int f() { return 0; }`` can be put on a
466 * ``SFS_None`` (in configuration: ``None``)
467 Never merge functions into a single line.
469 * ``SFS_InlineOnly`` (in configuration: ``InlineOnly``)
470 Only merge functions defined inside a class. Same as "inline",
471 except it does not implies "empty": i.e. top level empty functions
472 are not merged either.
485 * ``SFS_Empty`` (in configuration: ``Empty``)
486 Only merge empty functions.
495 * ``SFS_Inline`` (in configuration: ``Inline``)
496 Only merge functions defined inside a class. Implies "empty".
508 * ``SFS_All`` (in configuration: ``All``)
509 Merge all functions fitting on a single line.
520 **AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``)
521 If ``true``, ``if (a) return;`` can be put on a single line.
525 * ``SIS_Never`` (in configuration: ``Never``)
526 Never put short ifs on the same line.
536 * ``SIS_WithoutElse`` (in configuration: ``WithoutElse``)
537 Without else put short ifs on the same line only if
538 the else is not a compound statement.
546 * ``SIS_Always`` (in configuration: ``Always``)
547 Always put short ifs on the same line if
548 the else is not a compound statement or not.
559 **AllowShortLambdasOnASingleLine** (``ShortLambdaStyle``)
560 Dependent on the value, ``auto lambda []() { return 0; }`` can be put on a
565 * ``SLS_None`` (in configuration: ``None``)
566 Never merge lambdas into a single line.
568 * ``SLS_Empty`` (in configuration: ``Empty``)
569 Only merge empty lambdas.
573 auto lambda = [](int a) {}
574 auto lambda2 = [](int a) {
578 * ``SLS_Inline`` (in configuration: ``Inline``)
579 Merge lambda into a single line if argument of a function.
583 auto lambda = [](int a) {
586 sort(a.begin(), a.end(), ()[] { return x < y; })
588 * ``SLS_All`` (in configuration: ``All``)
589 Merge all lambdas fitting on a single line.
593 auto lambda = [](int a) {}
594 auto lambda2 = [](int a) { return a; };
598 **AllowShortLoopsOnASingleLine** (``bool``)
599 If ``true``, ``while (true) continue;`` can be put on a single
602 **AlwaysBreakAfterDefinitionReturnType** (``DefinitionReturnTypeBreakingStyle``)
603 The function definition return type breaking style to use. This
604 option is **deprecated** and is retained for backwards compatibility.
608 * ``DRTBS_None`` (in configuration: ``None``)
609 Break after return type automatically.
610 ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
612 * ``DRTBS_All`` (in configuration: ``All``)
613 Always break after the return type.
615 * ``DRTBS_TopLevel`` (in configuration: ``TopLevel``)
616 Always break after the return types of top-level functions.
620 **AlwaysBreakAfterReturnType** (``ReturnTypeBreakingStyle``)
621 The function declaration return type breaking style to use.
625 * ``RTBS_None`` (in configuration: ``None``)
626 Break after return type automatically.
627 ``PenaltyReturnTypeOnItsOwnLine`` is taken into account.
632 int f() { return 0; };
635 int f() { return 1; }
637 * ``RTBS_All`` (in configuration: ``All``)
638 Always break after the return type.
655 * ``RTBS_TopLevel`` (in configuration: ``TopLevel``)
656 Always break after the return types of top-level functions.
661 int f() { return 0; };
670 * ``RTBS_AllDefinitions`` (in configuration: ``AllDefinitions``)
671 Always break after the return type of function definitions.
687 * ``RTBS_TopLevelDefinitions`` (in configuration: ``TopLevelDefinitions``)
688 Always break after the return type of top-level definitions.
693 int f() { return 0; };
703 **AlwaysBreakBeforeMultilineStrings** (``bool``)
704 If ``true``, always break before multiline string literals.
706 This flag is mean to make cases where there are multiple multiline strings
707 in a file look more consistent. Thus, it will only take effect if wrapping
708 the string at that point leads to it being indented
709 ``ContinuationIndentWidth`` spaces from the start of the line.
714 aaaa = vs. aaaa = "bbbb"
718 **AlwaysBreakTemplateDeclarations** (``BreakTemplateDeclarationsStyle``)
719 The template declaration breaking style to use.
723 * ``BTDS_No`` (in configuration: ``No``)
724 Do not force break before declaration.
725 ``PenaltyBreakTemplateDeclaration`` is taken into account.
729 template <typename T> T foo() {
731 template <typename T> T foo(int aaaaaaaaaaaaaaaaaaaaa,
732 int bbbbbbbbbbbbbbbbbbbbb) {
735 * ``BTDS_MultiLine`` (in configuration: ``MultiLine``)
736 Force break after template declaration only when the following
737 declaration spans multiple lines.
741 template <typename T> T foo() {
743 template <typename T>
744 T foo(int aaaaaaaaaaaaaaaaaaaaa,
745 int bbbbbbbbbbbbbbbbbbbbb) {
748 * ``BTDS_Yes`` (in configuration: ``Yes``)
749 Always break after template declaration.
753 template <typename T>
756 template <typename T>
757 T foo(int aaaaaaaaaaaaaaaaaaaaa,
758 int bbbbbbbbbbbbbbbbbbbbb) {
763 **BinPackArguments** (``bool``)
764 If ``false``, a function call's arguments will either be all on the
765 same line or will have one line each.
771 f(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa,
772 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
777 f(aaaaaaaaaaaaaaaaaaaa,
778 aaaaaaaaaaaaaaaaaaaa,
779 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
782 **BinPackParameters** (``bool``)
783 If ``false``, a function declaration's or function definition's
784 parameters will either all be on the same line or will have one line each.
789 void f(int aaaaaaaaaaaaaaaaaaaa, int aaaaaaaaaaaaaaaaaaaa,
790 int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
793 void f(int aaaaaaaaaaaaaaaaaaaa,
794 int aaaaaaaaaaaaaaaaaaaa,
795 int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
797 **BraceWrapping** (``BraceWrappingFlags``)
798 Control of individual brace wrapping cases.
800 If ``BreakBeforeBraces`` is set to ``BS_Custom``, use this to specify how
801 each individual brace case should be handled. Otherwise, this is ignored.
806 BreakBeforeBraces: Custom
810 SplitEmptyFunction: false
812 Nested configuration flags:
815 * ``bool AfterCaseLabel`` Wrap case labels.
820 switch (foo) { vs. switch (foo) {
832 * ``bool AfterClass`` Wrap class definitions.
843 * ``BraceWrappingAfterControlStatementStyle AfterControlStatement``
844 Wrap control statements (``if``/``for``/``while``/``switch``/..).
848 * ``BWACS_Never`` (in configuration: ``Never``)
849 Never wrap braces after a control statement.
856 for (int i = 0; i < 10; ++i) {
859 * ``BWACS_MultiLine`` (in configuration: ``MultiLine``)
860 Only wrap braces after a multi-line control statement.
872 * ``BWACS_Always`` (in configuration: ``Always``)
873 Always wrap braces after a control statement.
881 for (int i = 0; i < 10; ++i)
885 * ``bool AfterEnum`` Wrap enum definitions.
898 * ``bool AfterFunction`` Wrap function definitions.
915 * ``bool AfterNamespace`` Wrap namespace definitions.
932 * ``bool AfterObjCDeclaration`` Wrap ObjC definitions (interfaces, implementations...).
933 @autoreleasepool and @synchronized blocks are wrapped
934 according to `AfterControlStatement` flag.
936 * ``bool AfterStruct`` Wrap struct definitions.
951 * ``bool AfterUnion`` Wrap union definitions.
966 * ``bool AfterExternBlock`` Wrap extern blocks.
981 * ``bool BeforeCatch`` Wrap before ``catch``.
998 * ``bool BeforeElse`` Wrap before ``else``.
1013 * ``bool BeforeLambdaBody`` Wrap lambda block.
1031 * ``bool BeforeWhile`` Wrap before ``while``.
1046 * ``bool IndentBraces`` Indent the wrapped braces themselves.
1048 * ``bool SplitEmptyFunction`` If ``false``, empty function body can be put on a single line.
1049 This option is used only if the opening brace of the function has
1050 already been wrapped, i.e. the `AfterFunction` brace wrapping mode is
1051 set, and the function could/should not be put on a single line (as per
1052 `AllowShortFunctionsOnASingleLine` and constructor formatting options).
1060 * ``bool SplitEmptyRecord`` If ``false``, empty record (e.g. class, struct or union) body
1061 can be put on a single line. This option is used only if the opening
1062 brace of the record has already been wrapped, i.e. the `AfterClass`
1063 (for classes) brace wrapping mode is set.
1067 class Foo vs. class Foo
1071 * ``bool SplitEmptyNamespace`` If ``false``, empty namespace body can be put on a single line.
1072 This option is used only if the opening brace of the namespace has
1073 already been wrapped, i.e. the `AfterNamespace` brace wrapping mode is
1078 namespace Foo vs. namespace Foo
1083 **BreakAfterJavaFieldAnnotations** (``bool``)
1084 Break after each annotation on a field in Java files.
1086 .. code-block:: java
1089 @Partial vs. @Partial @Mock DataLoad loader;
1093 **BreakBeforeBinaryOperators** (``BinaryOperatorStyle``)
1094 The way to wrap binary operators.
1098 * ``BOS_None`` (in configuration: ``None``)
1099 Break after operators.
1103 LooooooooooongType loooooooooooooooooooooongVariable =
1104 someLooooooooooooooooongFunction();
1106 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
1107 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
1108 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa &&
1109 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
1110 ccccccccccccccccccccccccccccccccccccccccc;
1112 * ``BOS_NonAssignment`` (in configuration: ``NonAssignment``)
1113 Break before operators that aren't assignments.
1117 LooooooooooongType loooooooooooooooooooooongVariable =
1118 someLooooooooooooooooongFunction();
1120 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1121 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1122 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1123 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1124 > ccccccccccccccccccccccccccccccccccccccccc;
1126 * ``BOS_All`` (in configuration: ``All``)
1127 Break before operators.
1131 LooooooooooongType loooooooooooooooooooooongVariable
1132 = someLooooooooooooooooongFunction();
1134 bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1135 + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1136 == aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1137 && aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
1138 > ccccccccccccccccccccccccccccccccccccccccc;
1142 **BreakBeforeBraces** (``BraceBreakingStyle``)
1143 The brace breaking style to use.
1147 * ``BS_Attach`` (in configuration: ``Attach``)
1148 Always attach braces to surrounding context.
1156 void foo() { bar(); }
1161 enum X : int { A, B };
1163 * ``BS_Linux`` (in configuration: ``Linux``)
1164 Like ``Attach``, but break before braces on function, namespace and
1173 void foo() { bar(); }
1180 enum X : int { A, B };
1182 * ``BS_Mozilla`` (in configuration: ``Mozilla``)
1183 Like ``Attach``, but break before braces on enum, function, and record
1192 void foo() { bar(); }
1199 enum X : int { A, B };
1201 * ``BS_Stroustrup`` (in configuration: ``Stroustrup``)
1202 Like ``Attach``, but break before function definitions, ``catch``, and
1212 void foo() { bar(); }
1219 enum X : int { A, B };
1221 * ``BS_Allman`` (in configuration: ``Allman``)
1222 Always break before braces.
1233 void foo() { bar(); }
1249 * ``BS_Whitesmiths`` (in configuration: ``Whitesmiths``)
1250 Like ``Allman`` but always indent braces and line up code with braces.
1261 void foo() { bar(); }
1277 * ``BS_GNU`` (in configuration: ``GNU``)
1278 Always break before braces and add an extra level of indentation to
1279 braces of control statements, not to those of class, function
1280 or other definitions.
1291 void foo() { bar(); }
1307 * ``BS_WebKit`` (in configuration: ``WebKit``)
1308 Like ``Attach``, but break before functions.
1316 void foo() { bar(); }
1322 enum X : int { A, B };
1324 * ``BS_Custom`` (in configuration: ``Custom``)
1325 Configure each individual brace in `BraceWrapping`.
1329 **BreakBeforeTernaryOperators** (``bool``)
1330 If ``true``, ternary operators will be placed after line breaks.
1335 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription
1337 : SecondValueVeryVeryVeryVeryLong;
1340 veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongDescription ?
1342 SecondValueVeryVeryVeryVeryLong;
1344 **BreakConstructorInitializers** (``BreakConstructorInitializersStyle``)
1345 The constructor initializers style to use.
1349 * ``BCIS_BeforeColon`` (in configuration: ``BeforeColon``)
1350 Break constructor initializers before the colon and after the commas.
1358 * ``BCIS_BeforeComma`` (in configuration: ``BeforeComma``)
1359 Break constructor initializers before the colon and commas, and align
1360 the commas with the colon.
1368 * ``BCIS_AfterColon`` (in configuration: ``AfterColon``)
1369 Break constructor initializers after the colon and commas.
1379 **BreakInheritanceList** (``BreakInheritanceListStyle``)
1380 The inheritance list style to use.
1384 * ``BILS_BeforeColon`` (in configuration: ``BeforeColon``)
1385 Break inheritance list before the colon and after the commas.
1394 * ``BILS_BeforeComma`` (in configuration: ``BeforeComma``)
1395 Break inheritance list before the colon and commas, and align
1396 the commas with the colon.
1405 * ``BILS_AfterColon`` (in configuration: ``AfterColon``)
1406 Break inheritance list after the colon and commas.
1417 **BreakStringLiterals** (``bool``)
1418 Allow breaking string literals when formatting.
1423 const char* x = "veryVeryVeryVeryVeryVe"
1424 "ryVeryVeryVeryVeryVery"
1429 "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
1431 **ColumnLimit** (``unsigned``)
1434 A column limit of ``0`` means that there is no column limit. In this case,
1435 clang-format will respect the input's line breaking decisions within
1436 statements unless they contradict other rules.
1438 **CommentPragmas** (``std::string``)
1439 A regular expression that describes comments with special meaning,
1440 which should not be split into lines or otherwise changed.
1444 // CommentPragmas: '^ FOOBAR pragma:'
1445 // Will leave the following line unaffected
1446 #include <vector> // FOOBAR pragma: keep
1448 **CompactNamespaces** (``bool``)
1449 If ``true``, consecutive namespace declarations will be on the same
1450 line. If ``false``, each namespace is declared on a new line.
1455 namespace Foo { namespace Bar {
1464 If it does not fit on a single line, the overflowing namespaces get
1469 namespace Foo { namespace Bar {
1473 **ConstructorInitializerAllOnOneLineOrOnePerLine** (``bool``)
1474 If the constructor initializers don't fit on a line, put each
1475 initializer on its own line.
1480 SomeClass::Constructor()
1481 : aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa) {
1486 SomeClass::Constructor()
1487 : aaaaaaaa(aaaaaaaa), aaaaaaaa(aaaaaaaa),
1488 aaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaa) {
1492 **ConstructorInitializerIndentWidth** (``unsigned``)
1493 The number of characters to use for indentation of constructor
1494 initializer lists as well as inheritance lists.
1496 **ContinuationIndentWidth** (``unsigned``)
1497 Indent width for line continuations.
1501 ContinuationIndentWidth: 2
1503 int i = // VeryVeryVeryVeryVeryLongComment
1504 longFunction( // Again a long comment
1507 **Cpp11BracedListStyle** (``bool``)
1508 If ``true``, format braced lists as best suited for C++11 braced
1511 Important differences:
1512 - No spaces inside the braced list.
1513 - No line break before the closing brace.
1514 - Indentation with the continuation indent, not with the block indent.
1516 Fundamentally, C++11 braced lists are formatted exactly like function
1517 calls would be formatted in their place. If the braced list follows a name
1518 (e.g. a type or variable name), clang-format formats as if the ``{}`` were
1519 the parentheses of a function call with that name. If there is no name,
1520 a zero-length name is assumed.
1525 vector<int> x{1, 2, 3, 4}; vs. vector<int> x{ 1, 2, 3, 4 };
1526 vector<T> x{{}, {}, {}, {}}; vector<T> x{ {}, {}, {}, {} };
1527 f(MyMap[{composite, key}]); f(MyMap[{ composite, key }]);
1528 new int[3]{1, 2, 3}; new int[3]{ 1, 2, 3 };
1530 **DeriveLineEnding** (``bool``)
1531 Analyze the formatted file for the most used line ending (``\r\n``
1532 or ``\n``). ``UseCRLF`` is only used as a fallback if none can be derived.
1534 **DerivePointerAlignment** (``bool``)
1535 If ``true``, analyze the formatted file for the most common
1536 alignment of ``&`` and ``*``.
1537 Pointer and reference alignment styles are going to be updated according
1538 to the preferences found in the file.
1539 ``PointerAlignment`` is then used only as fallback.
1541 **DisableFormat** (``bool``)
1542 Disables formatting completely.
1544 **ExperimentalAutoDetectBinPacking** (``bool``)
1545 If ``true``, clang-format detects whether function calls and
1546 definitions are formatted with one parameter per line.
1548 Each call can be bin-packed, one-per-line or inconclusive. If it is
1549 inconclusive, e.g. completely on one line, but a decision needs to be
1550 made, clang-format analyzes whether there are other bin-packed cases in
1551 the input file and act accordingly.
1553 NOTE: This is an experimental flag, that might go away or be renamed. Do
1554 not use this in config files, etc. Use at your own risk.
1556 **FixNamespaceComments** (``bool``)
1557 If ``true``, clang-format adds missing namespace end comments and
1558 fixes invalid existing ones.
1563 namespace a { vs. namespace a {
1567 **ForEachMacros** (``std::vector<std::string>``)
1568 A vector of macros that should be interpreted as foreach loops
1569 instead of as function calls.
1571 These are expected to be macros of the form:
1575 FOREACH(<variable-declaration>, ...)
1578 In the .clang-format configuration file, this can be configured like:
1580 .. code-block:: yaml
1582 ForEachMacros: ['RANGES_FOR', 'FOREACH']
1584 For example: BOOST_FOREACH.
1586 **IncludeBlocks** (``IncludeBlocksStyle``)
1587 Dependent on the value, multiple ``#include`` blocks can be sorted
1588 as one and divided based on category.
1592 * ``IBS_Preserve`` (in configuration: ``Preserve``)
1593 Sort each ``#include`` block separately.
1597 #include "b.h" into #include "b.h"
1599 #include <lib/main.h> #include "a.h"
1600 #include "a.h" #include <lib/main.h>
1602 * ``IBS_Merge`` (in configuration: ``Merge``)
1603 Merge multiple ``#include`` blocks together and sort as one.
1607 #include "b.h" into #include "a.h"
1609 #include <lib/main.h> #include <lib/main.h>
1612 * ``IBS_Regroup`` (in configuration: ``Regroup``)
1613 Merge multiple ``#include`` blocks together and sort as one.
1614 Then split into groups based on category priority. See
1615 ``IncludeCategories``.
1619 #include "b.h" into #include "a.h"
1621 #include <lib/main.h>
1622 #include "a.h" #include <lib/main.h>
1626 **IncludeCategories** (``std::vector<IncludeCategory>``)
1627 Regular expressions denoting the different ``#include`` categories
1628 used for ordering ``#includes``.
1631 <https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html>`_
1632 regular expressions are supported.
1634 These regular expressions are matched against the filename of an include
1635 (including the <> or "") in order. The value belonging to the first
1636 matching regular expression is assigned and ``#includes`` are sorted first
1637 according to increasing category number and then alphabetically within
1640 If none of the regular expressions match, INT_MAX is assigned as
1641 category. The main header for a source file automatically gets category 0.
1642 so that it is generally kept at the beginning of the ``#includes``
1643 (https://llvm.org/docs/CodingStandards.html#include-style). However, you
1644 can also assign negative priorities if you have certain headers that
1645 always need to be first.
1647 There is a third and optional field ``SortPriority`` which can used while
1648 ``IncludeBloks = IBS_Regroup`` to define the priority in which ``#includes``
1649 should be ordered, and value of ``Priority`` defines the order of
1650 ``#include blocks`` and also enables to group ``#includes`` of different
1651 priority for order.``SortPriority`` is set to the value of ``Priority``
1652 as default if it is not assigned.
1654 To configure this in the .clang-format file, use:
1656 .. code-block:: yaml
1659 - Regex: '^"(llvm|llvm-c|clang|clang-c)/'
1662 - Regex: '^(<|"(gtest|gmock|isl|json)/)'
1664 - Regex: '<[[:alnum:].]+>'
1670 **IncludeIsMainRegex** (``std::string``)
1671 Specify a regular expression of suffixes that are allowed in the
1672 file-to-main-include mapping.
1674 When guessing whether a #include is the "main" include (to assign
1675 category 0, see above), use this regex of allowed suffixes to the header
1676 stem. A partial match is done, so that:
1677 - "" means "arbitrary suffix"
1678 - "$" means "no suffix"
1680 For example, if configured to "(_test)?$", then a header a.h would be seen
1681 as the "main" include in both a.cc and a_test.cc.
1683 **IncludeIsMainSourceRegex** (``std::string``)
1684 Specify a regular expression for files being formatted
1685 that are allowed to be considered "main" in the
1686 file-to-main-include mapping.
1688 By default, clang-format considers files as "main" only when they end
1689 with: ``.c``, ``.cc``, ``.cpp``, ``.c++``, ``.cxx``, ``.m`` or ``.mm``
1691 For these files a guessing of "main" include takes place
1692 (to assign category 0, see above). This config option allows for
1693 additional suffixes and extensions for files to be considered as "main".
1695 For example, if this option is configured to ``(Impl\.hpp)$``,
1696 then a file ``ClassImpl.hpp`` is considered "main" (in addition to
1697 ``Class.c``, ``Class.cc``, ``Class.cpp`` and so on) and "main
1698 include file" logic will be executed (with *IncludeIsMainRegex* setting
1699 also being respected in later phase). Without this option set,
1700 ``ClassImpl.hpp`` would not have the main include file put on top
1701 before any other include.
1703 **IndentCaseBlocks** (``bool``)
1704 Indent case label blocks one level from the case label.
1706 When ``false``, the block following the case label uses the same
1707 indentation level as for the case label, treating the case label the same
1709 When ``true``, the block gets indented as a scope block.
1714 switch (fool) { vs. switch (fool) {
1726 **IndentCaseLabels** (``bool``)
1727 Indent case labels one level from the switch statement.
1729 When ``false``, use the same indentation level as for the switch
1730 statement. Switch statement body is always indented one level more than
1731 case labels (except the first block following the case label, which
1732 itself indents the code - unless IndentCaseBlocks is enabled).
1737 switch (fool) { vs. switch (fool) {
1745 **IndentExternBlock** (``IndentExternBlockStyle``)
1746 IndentExternBlockStyle is the type of indenting of extern blocks.
1750 * ``IEBS_AfterExternBlock`` (in configuration: ``AfterExternBlock``)
1751 Backwards compatible with AfterExternBlock's indenting.
1755 IndentExternBlock: AfterExternBlock
1756 BraceWrapping.AfterExternBlock: true
1765 IndentExternBlock: AfterExternBlock
1766 BraceWrapping.AfterExternBlock: false
1771 * ``IEBS_NoIndent`` (in configuration: ``NoIndent``)
1772 Does not indent extern blocks.
1780 * ``IEBS_Indent`` (in configuration: ``Indent``)
1781 Indents extern blocks.
1791 **IndentGotoLabels** (``bool``)
1794 When ``false``, goto labels are flushed left.
1799 int f() { vs. int f() {
1800 if (foo()) { if (foo()) {
1808 **IndentPPDirectives** (``PPDirectiveIndentStyle``)
1809 The preprocessor directive indenting style to use.
1813 * ``PPDIS_None`` (in configuration: ``None``)
1814 Does not indent any directives.
1824 * ``PPDIS_AfterHash`` (in configuration: ``AfterHash``)
1825 Indents directives after the hash.
1835 * ``PPDIS_BeforeHash`` (in configuration: ``BeforeHash``)
1836 Indents directives before the hash.
1848 **IndentWidth** (``unsigned``)
1849 The number of columns to use for indentation.
1862 **IndentWrappedFunctionNames** (``bool``)
1863 Indent if a function definition or declaration is wrapped after the
1869 LoooooooooooooooooooooooooooooooooooooooongReturnType
1870 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
1873 LoooooooooooooooooooooooooooooooooooooooongReturnType
1874 LoooooooooooooooooooooooooooooooongFunctionDeclaration();
1876 **InsertTrailingCommas** (``TrailingCommaStyle``)
1877 If set to ``TCS_Wrapped`` will insert trailing commas in container
1878 literals (arrays and objects) that wrap across multiple lines.
1879 It is currently only available for JavaScript
1880 and disabled by default ``TCS_None``.
1881 ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
1882 as inserting the comma disables bin-packing.
1888 aaaaaaaaaaaaaaaaaaaaaaaaaa,
1889 aaaaaaaaaaaaaaaaaaaaaaaaaa,
1890 aaaaaaaaaaaaaaaaaaaaaaaaaa,
1896 * ``TCS_None`` (in configuration: ``None``)
1897 Do not insert trailing commas.
1899 * ``TCS_Wrapped`` (in configuration: ``Wrapped``)
1900 Insert trailing commas in container literals that were wrapped over
1901 multiple lines. Note that this is conceptually incompatible with
1902 bin-packing, because the trailing comma is used as an indicator
1903 that a container should be formatted one-per-line (i.e. not bin-packed).
1904 So inserting a trailing comma counteracts bin-packing.
1908 **JavaImportGroups** (``std::vector<std::string>``)
1909 A vector of prefixes ordered by the desired groups for Java imports.
1911 Each group is separated by a newline. Static imports will also follow the
1912 same grouping convention above all non-static imports. One group's prefix
1913 can be a subset of another - the longest prefix is always matched. Within
1914 a group, the imports are ordered lexicographically.
1916 In the .clang-format configuration file, this can be configured like
1917 in the following yaml example. This will result in imports being
1918 formatted as in the Java example below.
1920 .. code-block:: yaml
1922 JavaImportGroups: ['com.example', 'com', 'org']
1925 .. code-block:: java
1927 import static com.example.function1;
1929 import static com.test.function2;
1931 import static org.example.function3;
1933 import com.example.ClassA;
1934 import com.example.Test;
1935 import com.example.a.ClassB;
1937 import com.test.ClassC;
1939 import org.example.ClassD;
1941 **JavaScriptQuotes** (``JavaScriptQuoteStyle``)
1942 The JavaScriptQuoteStyle to use for JavaScript strings.
1946 * ``JSQS_Leave`` (in configuration: ``Leave``)
1947 Leave string quotes as they are.
1954 * ``JSQS_Single`` (in configuration: ``Single``)
1955 Always use single quotes.
1962 * ``JSQS_Double`` (in configuration: ``Double``)
1963 Always use double quotes.
1972 **JavaScriptWrapImports** (``bool``)
1973 Whether to wrap JavaScript import/export statements.
1979 VeryLongImportsAreAnnoying,
1980 VeryLongImportsAreAnnoying,
1981 VeryLongImportsAreAnnoying,
1982 } from 'some/module.js'
1985 import {VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying, VeryLongImportsAreAnnoying,} from "some/module.js"
1987 **KeepEmptyLinesAtTheStartOfBlocks** (``bool``)
1988 If true, the empty line at the start of blocks is kept.
1993 if (foo) { vs. if (foo) {
1998 **Language** (``LanguageKind``)
1999 Language, this format style is targeted at.
2003 * ``LK_None`` (in configuration: ``None``)
2006 * ``LK_Cpp`` (in configuration: ``Cpp``)
2007 Should be used for C, C++.
2009 * ``LK_CSharp`` (in configuration: ``CSharp``)
2010 Should be used for C#.
2012 * ``LK_Java`` (in configuration: ``Java``)
2013 Should be used for Java.
2015 * ``LK_JavaScript`` (in configuration: ``JavaScript``)
2016 Should be used for JavaScript.
2018 * ``LK_ObjC`` (in configuration: ``ObjC``)
2019 Should be used for Objective-C, Objective-C++.
2021 * ``LK_Proto`` (in configuration: ``Proto``)
2022 Should be used for Protocol Buffers
2023 (https://developers.google.com/protocol-buffers/).
2025 * ``LK_TableGen`` (in configuration: ``TableGen``)
2026 Should be used for TableGen code.
2028 * ``LK_TextProto`` (in configuration: ``TextProto``)
2029 Should be used for Protocol Buffer messages in text format
2030 (https://developers.google.com/protocol-buffers/).
2034 **MacroBlockBegin** (``std::string``)
2035 A regular expression matching macros that start a block.
2040 MacroBlockBegin: "^NS_MAP_BEGIN|\
2063 **MacroBlockEnd** (``std::string``)
2064 A regular expression matching macros that end a block.
2066 **MaxEmptyLinesToKeep** (``unsigned``)
2067 The maximum number of consecutive empty lines to keep.
2071 MaxEmptyLinesToKeep: 1 vs. MaxEmptyLinesToKeep: 0
2075 i = foo(); return i;
2080 **NamespaceIndentation** (``NamespaceIndentationKind``)
2081 The indentation used for namespaces.
2085 * ``NI_None`` (in configuration: ``None``)
2086 Don't indent in namespaces.
2097 * ``NI_Inner`` (in configuration: ``Inner``)
2098 Indent only in inner namespaces (nested in other namespaces).
2109 * ``NI_All`` (in configuration: ``All``)
2110 Indent in all namespaces.
2123 **NamespaceMacros** (``std::vector<std::string>``)
2124 A vector of macros which are used to open namespace blocks.
2126 These are expected to be macros of the form:
2130 NAMESPACE(<namespace-name>, ...) {
2134 For example: TESTSUITE
2136 **ObjCBinPackProtocolList** (``BinPackStyle``)
2137 Controls bin-packing Objective-C protocol conformance list
2138 items into as few lines as possible when they go over ``ColumnLimit``.
2140 If ``Auto`` (the default), delegates to the value in
2141 ``BinPackParameters``. If that is ``true``, bin-packs Objective-C
2142 protocol conformance list items into as few lines as possible
2143 whenever they go over ``ColumnLimit``.
2145 If ``Always``, always bin-packs Objective-C protocol conformance
2146 list items into as few lines as possible whenever they go over
2149 If ``Never``, lays out Objective-C protocol conformance list items
2150 onto individual lines whenever they go over ``ColumnLimit``.
2153 .. code-block:: objc
2155 Always (or Auto, if BinPackParameters=true):
2156 @interface ccccccccccccc () <
2157 ccccccccccccc, ccccccccccccc,
2158 ccccccccccccc, ccccccccccccc> {
2161 Never (or Auto, if BinPackParameters=false):
2162 @interface ddddddddddddd () <
2171 * ``BPS_Auto`` (in configuration: ``Auto``)
2172 Automatically determine parameter bin-packing behavior.
2174 * ``BPS_Always`` (in configuration: ``Always``)
2175 Always bin-pack parameters.
2177 * ``BPS_Never`` (in configuration: ``Never``)
2178 Never bin-pack parameters.
2182 **ObjCBlockIndentWidth** (``unsigned``)
2183 The number of characters to use for indentation of ObjC blocks.
2185 .. code-block:: objc
2187 ObjCBlockIndentWidth: 4
2189 [operation setCompletionBlock:^{
2190 [self onOperationDone];
2193 **ObjCBreakBeforeNestedBlockParam** (``bool``)
2194 Break parameters list into lines when there is nested block
2195 parameters in a fuction call.
2202 [self.test1 t:self w:self callback:^(typeof(self) self, NSNumber
2212 callback:^(typeof(self) self, NSNumber *u, NSNumber *v) {
2217 **ObjCSpaceAfterProperty** (``bool``)
2218 Add a space after ``@property`` in Objective-C, i.e. use
2219 ``@property (readonly)`` instead of ``@property(readonly)``.
2221 **ObjCSpaceBeforeProtocolList** (``bool``)
2222 Add a space in front of an Objective-C protocol list, i.e. use
2223 ``Foo <Protocol>`` instead of ``Foo<Protocol>``.
2225 **PenaltyBreakAssignment** (``unsigned``)
2226 The penalty for breaking around an assignment operator.
2228 **PenaltyBreakBeforeFirstCallParameter** (``unsigned``)
2229 The penalty for breaking a function call after ``call(``.
2231 **PenaltyBreakComment** (``unsigned``)
2232 The penalty for each line break introduced inside a comment.
2234 **PenaltyBreakFirstLessLess** (``unsigned``)
2235 The penalty for breaking before the first ``<<``.
2237 **PenaltyBreakString** (``unsigned``)
2238 The penalty for each line break introduced inside a string literal.
2240 **PenaltyBreakTemplateDeclaration** (``unsigned``)
2241 The penalty for breaking after template declaration.
2243 **PenaltyExcessCharacter** (``unsigned``)
2244 The penalty for each character outside of the column limit.
2246 **PenaltyReturnTypeOnItsOwnLine** (``unsigned``)
2247 Penalty for putting the return type of a function onto its own
2250 **PointerAlignment** (``PointerAlignmentStyle``)
2251 Pointer and reference alignment style.
2255 * ``PAS_Left`` (in configuration: ``Left``)
2256 Align pointer to the left.
2262 * ``PAS_Right`` (in configuration: ``Right``)
2263 Align pointer to the right.
2269 * ``PAS_Middle`` (in configuration: ``Middle``)
2270 Align pointer in the middle.
2278 **RawStringFormats** (``std::vector<RawStringFormat>``)
2279 Defines hints for detecting supported languages code blocks in raw
2282 A raw string with a matching delimiter or a matching enclosing function
2283 name will be reformatted assuming the specified language based on the
2284 style for that language defined in the .clang-format file. If no style has
2285 been defined in the .clang-format file for the specific language, a
2286 predefined style given by 'BasedOnStyle' is used. If 'BasedOnStyle' is not
2287 found, the formatting is based on llvm style. A matching delimiter takes
2288 precedence over a matching enclosing function name for determining the
2289 language of the raw string contents.
2291 If a canonical delimiter is specified, occurrences of other delimiters for
2292 the same language will be updated to the canonical if possible.
2294 There should be at most one specification per language and each delimiter
2295 and enclosing function should not occur in multiple specifications.
2297 To configure this in the .clang-format file, use:
2299 .. code-block:: yaml
2302 - Language: TextProto
2307 - 'PARSE_TEXT_PROTO'
2308 BasedOnStyle: google
2314 CanonicalDelimiter: 'cc'
2316 **ReflowComments** (``bool``)
2317 If ``true``, clang-format will attempt to re-flow comments.
2322 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information
2323 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of information */
2326 // veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
2328 /* second veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongComment with plenty of
2331 **SortIncludes** (``bool``)
2332 If ``true``, clang-format will sort ``#includes``.
2337 #include "b.h" vs. #include "a.h"
2338 #include "a.h" #include "b.h"
2340 **SortUsingDeclarations** (``bool``)
2341 If ``true``, clang-format will sort using declarations.
2343 The order of using declarations is defined as follows:
2344 Split the strings by "::" and discard any initial empty strings. The last
2345 element of each list is a non-namespace name; all others are namespace
2346 names. Sort the lists of names lexicographically, where the sort order of
2347 individual names is that all non-namespace names come before all namespace
2348 names, and within those groups, names are in case-insensitive
2349 lexicographic order.
2354 using std::cout; vs. using std::cin;
2355 using std::cin; using std::cout;
2357 **SpaceAfterCStyleCast** (``bool``)
2358 If ``true``, a space is inserted after C style casts.
2363 (int) i; vs. (int)i;
2365 **SpaceAfterLogicalNot** (``bool``)
2366 If ``true``, a space is inserted after the logical not operator (``!``).
2371 ! someExpression(); vs. !someExpression();
2373 **SpaceAfterTemplateKeyword** (``bool``)
2374 If ``true``, a space will be inserted after the 'template' keyword.
2379 template <int> void foo(); vs. template<int> void foo();
2381 **SpaceBeforeAssignmentOperators** (``bool``)
2382 If ``false``, spaces will be removed before assignment operators.
2387 int a = 5; vs. int a= 5;
2390 **SpaceBeforeCpp11BracedList** (``bool``)
2391 If ``true``, a space will be inserted before a C++11 braced list
2392 used to initialize an object (after the preceding identifier or type).
2397 Foo foo { bar }; vs. Foo foo{ bar };
2399 vector<int> { 1, 2, 3 }; vector<int>{ 1, 2, 3 };
2400 new int[3] { 1, 2, 3 }; new int[3]{ 1, 2, 3 };
2402 **SpaceBeforeCtorInitializerColon** (``bool``)
2403 If ``false``, spaces will be removed before constructor initializer
2409 Foo::Foo() : a(a) {} Foo::Foo(): a(a) {}
2411 **SpaceBeforeInheritanceColon** (``bool``)
2412 If ``false``, spaces will be removed before inheritance colon.
2417 class Foo : Bar {} vs. class Foo: Bar {}
2419 **SpaceBeforeParens** (``SpaceBeforeParensOptions``)
2420 Defines in which cases to put a space before opening parentheses.
2424 * ``SBPO_Never`` (in configuration: ``Never``)
2425 Never put a space before opening parentheses.
2435 * ``SBPO_ControlStatements`` (in configuration: ``ControlStatements``)
2436 Put a space before opening parentheses only after control statement
2437 keywords (``for/if/while...``).
2447 * ``SBPO_ControlStatementsExceptForEachMacros`` (in configuration: ``ControlStatementsExceptForEachMacros``)
2448 Same as ``SBPO_ControlStatements`` except this option doesn't apply to
2449 ForEach macros. This is useful in projects where ForEach macros are
2450 treated as function calls instead of control statements.
2460 * ``SBPO_NonEmptyParentheses`` (in configuration: ``NonEmptyParentheses``)
2461 Put a space before opening parentheses only if the parentheses are not
2473 * ``SBPO_Always`` (in configuration: ``Always``)
2474 Always put a space before opening parentheses, except when it's
2475 prohibited by the syntax rules (in function-like macro definitions) or
2476 when determined by other style rules (after unary operators, opening
2489 **SpaceBeforeRangeBasedForLoopColon** (``bool``)
2490 If ``false``, spaces will be removed before range-based for loop
2496 for (auto v : values) {} vs. for(auto v: values) {}
2498 **SpaceBeforeSquareBrackets** (``bool``)
2499 If ``true``, spaces will be before ``[``.
2500 Lambdas will not be affected. Only the first ``[`` will get a space added.
2505 int a [5]; vs. int a[5];
2506 int a [5][5]; vs. int a[5][5];
2508 **SpaceInEmptyBlock** (``bool``)
2509 If ``true``, spaces will be inserted into ``{}``.
2514 void f() { } vs. void f() {}
2515 while (true) { } while (true) {}
2517 **SpaceInEmptyParentheses** (``bool``)
2518 If ``true``, spaces may be inserted into ``()``.
2523 void f( ) { vs. void f() {
2524 int x[] = {foo( ), bar( )}; int x[] = {foo(), bar()};
2525 if (true) { if (true) {
2530 **SpacesBeforeTrailingComments** (``unsigned``)
2531 The number of spaces before trailing line comments
2532 (``//`` - comments).
2534 This does not affect trailing block comments (``/*`` - comments) as
2535 those commonly have different usage patterns and a number of special
2540 SpacesBeforeTrailingComments: 3
2547 **SpacesInAngles** (``bool``)
2548 If ``true``, spaces will be inserted after ``<`` and before ``>``
2549 in template argument lists.
2554 static_cast< int >(arg); vs. static_cast<int>(arg);
2555 std::function< void(int) > fct; std::function<void(int)> fct;
2557 **SpacesInCStyleCastParentheses** (``bool``)
2558 If ``true``, spaces may be inserted into C style casts.
2563 x = ( int32 )y vs. x = (int32)y
2565 **SpacesInConditionalStatement** (``bool``)
2566 If ``true``, spaces will be inserted around if/for/switch/while
2572 if ( a ) { ... } vs. if (a) { ... }
2573 while ( i < 5 ) { ... } while (i < 5) { ... }
2575 **SpacesInContainerLiterals** (``bool``)
2576 If ``true``, spaces are inserted inside container literals (e.g.
2577 ObjC and Javascript array and dict literals).
2582 var arr = [ 1, 2, 3 ]; vs. var arr = [1, 2, 3];
2583 f({a : 1, b : 2, c : 3}); f({a: 1, b: 2, c: 3});
2585 **SpacesInParentheses** (``bool``)
2586 If ``true``, spaces will be inserted after ``(`` and before ``)``.
2591 t f( Deleted & ) & = delete; vs. t f(Deleted &) & = delete;
2593 **SpacesInSquareBrackets** (``bool``)
2594 If ``true``, spaces will be inserted after ``[`` and before ``]``.
2595 Lambdas without arguments or unspecified size array declarations will not
2601 int a[ 5 ]; vs. int a[5];
2602 std::unique_ptr<int[]> foo() {} // Won't be affected
2604 **Standard** (``LanguageStandard``)
2605 Parse and format C++ constructs compatible with this standard.
2610 vector<set<int> > x; vs. vector<set<int>> x;
2614 * ``LS_Cpp03`` (in configuration: ``c++03``)
2615 Parse and format as C++03.
2616 ``Cpp03`` is a deprecated alias for ``c++03``
2618 * ``LS_Cpp11`` (in configuration: ``c++11``)
2619 Parse and format as C++11.
2621 * ``LS_Cpp14`` (in configuration: ``c++14``)
2622 Parse and format as C++14.
2624 * ``LS_Cpp17`` (in configuration: ``c++17``)
2625 Parse and format as C++17.
2627 * ``LS_Cpp20`` (in configuration: ``c++20``)
2628 Parse and format as C++20.
2630 * ``LS_Latest`` (in configuration: ``Latest``)
2631 Parse and format using the latest supported language version.
2632 ``Cpp11`` is a deprecated alias for ``Latest``
2634 * ``LS_Auto`` (in configuration: ``Auto``)
2635 Automatic detection based on the input.
2639 **StatementMacros** (``std::vector<std::string>``)
2640 A vector of macros that should be interpreted as complete
2643 Typical macros are expressions, and require a semi-colon to be
2644 added; sometimes this is not the case, and this allows to make
2645 clang-format aware of such cases.
2647 For example: Q_UNUSED
2649 **TabWidth** (``unsigned``)
2650 The number of columns used for tab stops.
2652 **TypenameMacros** (``std::vector<std::string>``)
2653 A vector of macros that should be interpreted as type declarations
2654 instead of as function calls.
2656 These are expected to be macros of the form:
2662 In the .clang-format configuration file, this can be configured like:
2664 .. code-block:: yaml
2666 TypenameMacros: ['STACK_OF', 'LIST']
2668 For example: OpenSSL STACK_OF, BSD LIST_ENTRY.
2670 **UseCRLF** (``bool``)
2671 Use ``\r\n`` instead of ``\n`` for line breaks.
2672 Also used as fallback if ``DeriveLineEnding`` is true.
2674 **UseTab** (``UseTabStyle``)
2675 The way to use tab characters in the resulting file.
2679 * ``UT_Never`` (in configuration: ``Never``)
2682 * ``UT_ForIndentation`` (in configuration: ``ForIndentation``)
2683 Use tabs only for indentation.
2685 * ``UT_ForContinuationAndIndentation`` (in configuration: ``ForContinuationAndIndentation``)
2686 Fill all leading whitespace with tabs, and use spaces for alignment that
2687 appears within a line (e.g. consecutive assignments and declarations).
2689 * ``UT_AlignWithSpaces`` (in configuration: ``AlignWithSpaces``)
2690 Use tabs for line continuation and indentation, and spaces for
2693 * ``UT_Always`` (in configuration: ``Always``)
2694 Use tabs whenever we need to fill whitespace that spans at least from
2695 one tab stop to the next one.
2699 .. END_FORMAT_STYLE_OPTIONS
2701 Adding additional style options
2702 ===============================
2704 Each additional style option adds costs to the clang-format project. Some of
2705 these costs affect the clang-format development itself, as we need to make
2706 sure that any given combination of options work and that new features don't
2707 break any of the existing options in any way. There are also costs for end users
2708 as options become less discoverable and people have to think about and make a
2709 decision on options they don't really care about.
2711 The goal of the clang-format project is more on the side of supporting a
2712 limited set of styles really well as opposed to supporting every single style
2713 used by a codebase somewhere in the wild. Of course, we do want to support all
2714 major projects and thus have established the following bar for adding style
2715 options. Each new style option must ..
2717 * be used in a project of significant size (have dozens of contributors)
2718 * have a publicly accessible style guide
2719 * have a person willing to contribute and maintain patches
2724 A style similar to the `Linux Kernel style
2725 <https://www.kernel.org/doc/Documentation/CodingStyle>`_:
2727 .. code-block:: yaml
2732 BreakBeforeBraces: Linux
2733 AllowShortIfStatementsOnASingleLine: false
2734 IndentCaseLabels: false
2736 The result is (imagine that tabs are used for indentation here):
2748 do_something_else();
2754 do_something_completely_different();
2765 A style similar to the default Visual Studio formatting style:
2767 .. code-block:: yaml
2771 BreakBeforeBraces: Allman
2772 AllowShortIfStatementsOnASingleLine: false
2773 IndentCaseLabels: false
2789 do_something_else();
2795 do_somthing_completely_different();