{"slug": "clang-format-file", "title": "Clang format file.", "summary": "This is a configuration file for clang-format, a code formatting tool, created by Ingmar Delsink. It specifies formatting rules for C++ code, including a tab width and indent width of 4, no tab characters, and C++11 standard compatibility. The file also enables alignment of consecutive assignments and sets pointer alignment to the left.", "body_md": "# clang-format\n# Made by: Ingmar Delsink\n# https://ingmar.dels.ink\n# See http://clang.llvm.org/docs/ClangFormatStyleOptions.html\n# Tested with: clang-format version 3.7.1\n\n# General\n#########\n\n# The style used for all options not specifically set in the configuration.\n# This option is supported only in the clang-format configuration (both within -style='{...}' and the .clang-format file).\n# Possible values:\n#   LLVM A style complying with the LLVM coding standards\n#   Google A style complying with Google’s C++ style guide\n#   Chromium A style complying with Chromium’s style guide\n#   Mozilla A style complying with Mozilla’s style guide\n#   WebKit A style complying with WebKit’s style guide\n#BasedOnStyle:\n\n# TabWidth (unsigned)\n# The number of columns used for tab stops.\nTabWidth: 4\n\n# IndentWidth (unsigned)\n# The number of columns to use for indentation.\nIndentWidth: 4\n\n# UseTab (UseTabStyle)\n# The way to use tab characters in the resulting file.\n# Possible values:\n#   UT_Never (in configuration: Never) Never use tab.\n#   UT_ForIndentation (in configuration: ForIndentation) Use tabs only for indentation.\n#   UT_Always (in configuration: Always) Use tabs whenever we need to fill whitespace that spans at least from one tab stop to the next one.\nUseTab: Never\n\n# C++\n#####\n\n# Language (LanguageKind)\n# Language, this format style is targeted at.\n# Possible values:\n#   LK_None (in configuration: None) Do not use.\n#   LK_Cpp (in configuration: Cpp) Should be used for C, C++, ObjectiveC, ObjectiveC++.\n#   LK_Java (in configuration: Java) Should be used for Java.\n#   LK_JavaScript (in configuration: JavaScript) Should be used for JavaScript.\n#   LK_Proto (in configuration: Proto) Should be used for Protocol Buffers (https://developers.google.com/protocol-buffers/).\n#   LK_TableGen (in configuration: TableGen) Should be used for TableGen code.\nLanguage: Cpp\n\n# Standard (LanguageStandard)\n# Format compatible with this standard, e.g. use A<A<int> > instead of A<A<int>> for LS_Cpp03.\n# Possible values:\n#   LS_Cpp03 (in configuration: Cpp03) Use C++03-compatible syntax.\n#   LS_Cpp11 (in configuration: Cpp11) Use features of C++11 (e.g. A<A<int>> instead of A<A<int> >).\n#   LS_Auto (in configuration: Auto) Automatic detection based on the input.\nStandard: Cpp11\n\n# Pointer and reference alignment style. Possible values: Left, Right, Middle.\nPointerAlignment: Left\n\n# AccessModifierOffset (int)\n# The extra indent or outdent of access modifiers, e.g. public:.\nAccessModifierOffset: 0\n\n# AlignAfterOpenBracket (BracketAlignmentStyle)\n# If true, horizontally aligns arguments after an open bracket.\n# This applies to round brackets (parentheses), angle brackets and square brackets.\n# Possible values:\n#   BAS_Align (in configuration: Align) Align parameters on the open bracket, e.g.:\n#   someLongFunction(argument1,\n#                    argument2);\n#   BAS_DontAlign (in configuration: DontAlign) Don’t align, instead use ContinuationIndentWidth, e.g.:\n#   someLongFunction(argument1,\n#   argument2);\n#   BAS_AlwaysBreak (in configuration: AlwaysBreak) Always break after an open bracket, if the parameters don’t fit on a single line, e.g.:\n#   someLongFunction(\n#       argument1, argument2);\nAlignAfterOpenBracket: false\n\n# AlignConsecutiveAssignments (bool)\n# If true, aligns consecutive assignments.\n# This will align the assignment operators of consecutive lines. This will result in formattings like\n# int aaaa = 12;\n# int b    = 23;\n# int ccc  = 23;\nAlignConsecutiveAssignments: true\n\n# AlignEscapedNewlinesLeft (bool)\n# If true, aligns escaped newlines as far left as possible. Otherwise puts them into the right-most column.\nAlignEscapedNewlinesLeft: true\n\n# AlignOperands (bool)\n# If true, horizontally align operands of binary and ternary expressions.\n# Specifically, this aligns operands of a single expression that needs to be split over multiple lines, e.g.:\n# int aaa = bbbbbbbbbbbbbbb +\n#           ccccccccccccccc;\nAlignOperands: false\n\n# AlignTrailingComments (bool)\n# If true, aligns trailing comments.\nAlignTrailingComments: true\n\n# AllowAllParametersOfDeclarationOnNextLine (bool)\n# Allow putting all parameters of a function declaration onto the next line even if BinPackParameters is false.\nAllowAllParametersOfDeclarationOnNextLine: false\n\n# AllowShortBlocksOnASingleLine (bool)\n# Allows contracting simple braced statements to a single line.\nAllowShortBlocksOnASingleLine: false\n\n# AllowShortCaseLabelsOnASingleLine (bool)\n# If true, short case labels will be contracted to a single line.\nAllowShortCaseLabelsOnASingleLine: true\n\n# AllowShortFunctionsOnASingleLine (ShortFunctionStyle)\n# Dependent on the value, int f() { return 0; } can be put on a single line.\n# Possible values:\n#   SFS_None (in configuration: None) Never merge functions into a single line.\n#   SFS_Empty (in configuration: Empty) Only merge empty functions.\n#   SFS_Inline (in configuration: Inline) Only merge functions defined inside a class. Implies “empty”.\n#   SFS_All (in configuration: All) Merge all functions fitting on a single line.\nAllowShortFunctionsOnASingleLine: false\n\n# AllowShortIfStatementsOnASingleLine (bool)\n# If true, if (a) return; can be put on a single line.\nAllowShortIfStatementsOnASingleLine: false\n\n# AllowShortLoopsOnASingleLine (bool)\n# If true, while (true) continue; can be put on a single line.\nAllowShortLoopsOnASingleLine: false\n\n# AlwaysBreakBeforeMultilineStrings (bool)\n# If true, always break before multiline string literals.\n# This flag is mean to make cases where there are multiple multiline strings in a file look more consistent. Thus, it will only take effect if wrapping the string at that point leads to it being indented ContinuationIndentWidth spaces from the start of the line.\nAlwaysBreakBeforeMultilineStrings: false\n\n# AlwaysBreakTemplateDeclarations (bool)\n# If true, always break after the template<...> of a template declaration.\nAlwaysBreakTemplateDeclarations: false\n\n# BinPackArguments (bool)\n# If false, a function call’s arguments will either be all on the same line or will have one line each.\n#BinPackArguments: false\n\n# BinPackParameters (bool)\n# If false, a function declaration’s or function definition’s parameters will either all be on the same line or will have one line each.\nBinPackParameters: false\n\n# BraceWrapping (BraceWrappingFlags)\n# Control of individual brace wrapping cases.\n# If BreakBeforeBraces is set to BS_Custom, use this to specify how each individual brace case should be handled. Otherwise, this is ignored.\n# Nested configuration flags:\n#   bool AfterClass Wrap class definitions.\n#   bool AfterControlStatement Wrap control statements (if/for/while/switch/..).\n#   bool AfterEnum Wrap enum definitions.\n#   bool AfterFunction Wrap function definitions.\n#   bool AfterNamespace Wrap namespace definitions.\n#   bool AfterObjCDeclaration Wrap ObjC definitions (@autoreleasepool, interfaces, ..).\n#   bool AfterStruct Wrap struct definitions.\n#   bool AfterUnion Wrap union definitions.\n#   bool BeforeCatch Wrap before catch.\n#   bool BeforeElse Wrap before else.\n#   bool IndentBraces Indent the wrapped braces themselves.\n#BraceWrapping:\n\n# BreakAfterJavaFieldAnnotations (bool)\n# Break after each annotation on a field in Java files.\n#BreakAfterJavaFieldAnnotations:\n\n# BreakBeforeBinaryOperators (BinaryOperatorStyle)\n# The way to wrap binary operators.\n# Possible values:\n#   BOS_None (in configuration: None) Break after operators.\n#   BOS_NonAssignment (in configuration: NonAssignment) Break before operators that aren’t assignments.\n#   BOS_All (in configuration: All) Break before operators.\nBreakBeforeBinaryOperators: false\n\n# BreakBeforeBraces (BraceBreakingStyle)\n# The brace breaking style to use.\n# Possible values:\n#   BS_Attach (in configuration: Attach) Always attach braces to surrounding context.\n#   BS_Linux (in configuration: Linux) Like Attach, but break before braces on function, namespace and class definitions.\n#   BS_Mozilla (in configuration: Mozilla) Like Attach, but break before braces on enum, function, and record definitions.\n#   BS_Stroustrup (in configuration: Stroustrup) Like Attach, but break before function definitions, catch, and else.\n#   BS_Allman (in configuration: Allman) Always break before braces.\n#   BS_GNU (in configuration: GNU) Always break before braces and add an extra level of indentation to braces of control statements, not to those of class, function or other definitions.\n#   BS_WebKit (in configuration: WebKit) Like Attach, but break before functions.\n#   BS_Custom (in configuration: Custom) Configure each individual brace in BraceWrapping.\nBreakBeforeBraces: Attach\n\n# BreakBeforeTernaryOperators (bool)\n# If true, ternary operators will be placed after line breaks.\nBreakBeforeTernaryOperators: false\n\n# BreakConstructorInitializersBeforeComma (bool)\n# Always break constructor initializers before commas and align the commas with the colon.\nBreakConstructorInitializersBeforeComma: false\n\n# BreakStringLiterals (bool)\n# Allow breaking string literals when formatting.\n#BreakStringLiterals:\n\n# ColumnLimit (unsigned)\n# The column limit.\n# A column limit of 0 means that there is no column limit. In this case, clang-format will respect the input’s line breaking decisions within statements unless they contradict other rules.\nColumnLimit: 80\n\n# CommentPragmas (std::string)\n# A regular expression that describes comments with special meaning, which should not be split into lines or otherwise changed.\nCommentPragmas: ''\n\n# ConstructorInitializerAllOnOneLineOrOnePerLine (bool)\n# If the constructor initializers don’t fit on a line, put each initializer on its own line.\nConstructorInitializerAllOnOneLineOrOnePerLine: false\n\n# ConstructorInitializerIndentWidth (unsigned)\n# The number of characters to use for indentation of constructor initializer lists.\nConstructorInitializerIndentWidth: 0\n\n# ContinuationIndentWidth (unsigned)\n# Indent width for line continuations.\nContinuationIndentWidth: 0\n\n# Cpp11BracedListStyle (bool)\n# If true, format braced lists as best suited for C++11 braced lists.\n# Important differences: - No spaces inside the braced list. - No line break before the closing brace. - Indentation with the continuation indent, not with the block indent.\n# Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place. If the braced list follows a name (e.g. a type or variable name), clang-format formats as if the {} were the parentheses of a function call with that name. If there is no name, a zero-length name is assumed.\nCpp11BracedListStyle: false\n\n# DerivePointerAlignment (bool)\n# If true, analyze the formatted file for the most common alignment of & and \\*. PointerAlignment is then used only as fallback.\nDerivePointerBinding: false\n\n# DisableFormat (bool)\n# Disables formatting completely.\n#DisableFormat:\n\n# ExperimentalAutoDetectBinPacking (bool)\n# If true, clang-format detects whether function calls and definitions are formatted with one parameter per line.\n# Each call can be bin-packed, one-per-line or inconclusive. If it is inconclusive, e.g. completely on one line, but a decision needs to be made, clang-format analyzes whether there are other bin-packed cases in the input file and act accordingly.\n# NOTE: This is an experimental flag, that might go away or be renamed. Do not use this in config files, etc. Use at your own risk.\n#ExperimentalAutoDetectBinPacking:\n\n# ForEachMacros (std::vector<std::string>)\n# A vector of macros that should be interpreted as foreach loops instead of as function calls.\n# These are expected to be macros of the form:\n# FOREACH(<variable-declaration>, ...)\n#  <loop-body>\n# In the .clang-format configuration file, this can be configured like:\n# ForEachMacros: ['RANGES_FOR', 'FOREACH']\n# For example: BOOST_FOREACH.\n#ForEachMacros:\n\n# IncludeCategories (std::vector<IncludeCategory>)\n# Regular expressions denoting the different #include categories used for ordering #includes.\n# These regular expressions are matched against the filename of an include (including the <> or “”) in order. The value belonging to the first matching regular expression is assigned and #includes are sorted first according to increasing category number and then alphabetically within each category.\n# If none of the regular expressions match, INT_MAX is assigned as category. The main header for a source file automatically gets category 0. so that it is generally kept at the beginning of the #includes (http://llvm.org/docs/CodingStandards.html#include-style). However, you can also assign negative priorities if you have certain headers that always need to be first.\n# To configure this in the .clang-format file, use:\n# IncludeCategories:\n#   - Regex:           '^\"(llvm|llvm-c|clang|clang-c)/'\n#     Priority:        2\n#   - Regex:           '^(<|\"(gtest|isl|json)/)'\n#     Priority:        3\n#   - Regex:           '.\\*'\n#     Priority:        1\n#IncludeCategories:\n\n# IndentCaseLabels (bool)\n# Indent case labels one level from the switch statement.\n# When false, use the same indentation level as for the switch statement. Switch statement body is always indented one level more than case labels.\nIndentCaseLabels: false\n\n# IndentFunctionDeclarationAfterType (bool)\n# If true, indent when breaking function declarations which are not also definitions after the type.\nIndentFunctionDeclarationAfterType: false\n\n# IndentWrappedFunctionNames (bool)\n# Indent if a function definition or declaration is wrapped after the type.\n#IndentWrappedFunctionNames:\n\n# KeepEmptyLinesAtTheStartOfBlocks (bool)\n# If true, empty lines at the start of blocks are kept.\n#KeepEmptyLinesAtTheStartOfBlocks:\n\n# MacroBlockBegin (std::string)\n# A regular expression matching macros that start a block.\n#MacroBlockBegin:\n\n# MacroBlockEnd (std::string)\n# A regular expression matching macros that end a block.\n#MacroBlockEnd:\n\n# MaxEmptyLinesToKeep (unsigned)\n# The maximum number of consecutive empty lines to keep.\nMaxEmptyLinesToKeep: 2\n\n# NamespaceIndentation (NamespaceIndentationKind)\n# The indentation used for namespaces.\n# Possible values:\n#   NI_None (in configuration: None) Don’t indent in namespaces.\n#   NI_Inner (in configuration: Inner) Indent only in inner namespaces (nested in other namespaces).\n#   NI_All (in configuration: All) Indent in all namespaces.\nNamespaceIndentation: None\n\n# ObjCBlockIndentWidth (unsigned)\n# The number of characters to use for indentation of ObjC blocks.\n#ObjCBlockIndentWidth:\n\n# ObjCSpaceAfterProperty (bool)\n# Add a space after @property in Objective-C, i.e. use @property (readonly) instead of @property(readonly).\nObjCSpaceAfterProperty: true\n\n# ObjCSpaceBeforeProtocolList (bool)\n# Add a space in front of an Objective-C protocol list, i.e. use Foo <Protocol> instead of Foo<Protocol>.\nObjCSpaceBeforeProtocolList: true\n\n# PenaltyBreakBeforeFirstCallParameter (unsigned)\n# The penalty for breaking a function call after call(.\nPenaltyBreakBeforeFirstCallParameter: 100\n\n# PenaltyBreakComment (unsigned)\n# The penalty for each line break introduced inside a comment.\nPenaltyBreakComment: 100\n\n# PenaltyBreakFirstLessLess (unsigned)\n# The penalty for breaking before the first <<.\nPenaltyBreakFirstLessLess: 0\n\n# PenaltyBreakString (unsigned)\n# The penalty for each line break introduced inside a string literal.\nPenaltyBreakString: 100\n\n# PenaltyExcessCharacter (unsigned)\n# The penalty for each character outside of the column limit.\nPenaltyExcessCharacter: 1\n\n# PenaltyReturnTypeOnItsOwnLine (unsigned)\n# Penalty for putting the return type of a function onto its own line.\nPenaltyReturnTypeOnItsOwnLine: 20\n\n# PointerAlignment (PointerAlignmentStyle)\n# Pointer and reference alignment style.\n# Possible values:\n#   PAS_Left (in configuration: Left) Align pointer to the left.\n#   PAS_Right (in configuration: Right) Align pointer to the right.\n#   PAS_Middle (in configuration: Middle) Align pointer in the middle.\n#PointerAlignment:\n\n# ReflowComments (bool)\n# If true, clang-format will attempt to re-flow comments.\n#ReflowComments: true (from v3.9)\n\n# SortIncludes (bool)\n# If true, clang-format will sort #includes.\n#SortIncludes: false (from v3.9)\n\n# SpaceAfterCStyleCast (bool)\n# If true, a space may be inserted after C style casts.\nSpaceAfterCStyleCast: false\n\n# SpaceBeforeAssignmentOperators (bool)\n# If false, spaces will be removed before assignment operators.\nSpaceBeforeAssignmentOperators: true\n\n# SpaceBeforeParens (SpaceBeforeParensOptions)\n# Defines in which cases to put a space before opening parentheses.\n# Possible values:\n#   SBPO_Never (in configuration: Never) Never put a space before opening parentheses.\n#   SBPO_ControlStatements (in configuration: ControlStatements) Put a space before opening parentheses only after control statement keywords (for/if/while...).\n#   SBPO_Always (in configuration: Always) Always put a space before opening parentheses, except when it’s prohibited by the syntax rules (in function-like macro definitions) or when determined by other style rules (after unary operators, opening parentheses, etc.)\nSpaceBeforeParens: Always\n\n# SpaceInEmptyParentheses (bool)\n# If true, spaces may be inserted into ().\nSpaceInEmptyParentheses: false\n\n# SpacesBeforeTrailingComments (unsigned)\n# The number of spaces before trailing line comments (// - comments).\n# This does not affect trailing block comments (/* - comments) as those commonly have different usage patterns and a number of special cases.\nSpacesBeforeTrailingComments: 1\n\n# SpacesInAngles (bool)\n# If true, spaces will be inserted after < and before > in template argument lists.\nSpacesInAngles: false\n\n# SpacesInCStyleCastParentheses (bool)\n# If true, spaces may be inserted into C style casts.\nSpacesInCStyleCastParentheses: false\n\n# SpacesInContainerLiterals (bool)\n# If true, spaces are inserted inside container literals (e.g. ObjC and Javascript array and dict literals).\nSpacesInContainerLiterals: false\n\n# SpacesInParentheses (bool)\n# If true, spaces will be inserted after ( and before ).\nSpacesInParentheses: false\n\n# SpacesInSquareBrackets (bool)\n# If true, spaces will be inserted after [ and before ].\nSpacesInSquareBrackets: false\n", "url": "https://wpnews.pro/news/clang-format-file", "canonical_source": "https://gist.github.com/idelsink/c25049d8c987890935f4", "published_at": "2016-03-07 22:03:30+00:00", "updated_at": "2026-05-22 20:08:17.012148+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Ingmar Delsink", "LLVM", "Google", "Chromium", "Mozilla", "WebKit"], "alternates": {"html": "https://wpnews.pro/news/clang-format-file", "markdown": "https://wpnews.pro/news/clang-format-file.md", "text": "https://wpnews.pro/news/clang-format-file.txt", "jsonld": "https://wpnews.pro/news/clang-format-file.jsonld"}}