Excellent! I was considering doing this, but you were first.

Can you please simply run this and open a PR with all the changes to the source this does, so that we can discuss coding style? (Not intending to merge that PR as long as other PRs are still open, maybe.) - Maybe not needed while we're discussing this.

This is not about "totally breaks your coding style". But I like the bare, unconfigured clang style better.

• With its smaller indentation level and the placement of curlies, code becomes more concise.
• There is a school of thought that, to minimize readers' mental load, the most important stuff should come first in a line. Your style puts "," first in a line when a long list needs to be broken up. I think this looks weird.
• I think it valuable to have a predictable order of include statements. People seldomly actually read include statements, but a predictable order here sometimes reduces merge conflicts.

This is not about "totally breaks your coding style". But I like the bare, unconfigured clang style better.

I'll admit, I stole the style from QT, and made a few changes as the bare style for C++ made some stuff totally incomprehensible to me. :)

• With its smaller indentation level and the placement of curlies, code becomes more concise.

I prefer braces thusly:

{
  Code
}

• There is a school of thought that, to minimize readers' mental load, the most important stuff should come first in a line. Your style puts "," first in a line when a long list needs to be broken up. I think this looks weird.

Agreed, not sure exactly how to put the commas at the end of the previous line.

• I think it valuable to have a predictable order of include statements. People seldomly actually read include statements, but a predictable order here sometimes reduces merge conflicts.

Agreed, this puts system includes before local includes.

This PR was put here expressly to get the teams thoughts and make any changes first. Don't want to have to apply multiple mega merges. :)

I prefer the

if (...) {
} else {
}

but its not of much importance, so we can have the braces your way. (Depending on what others say, if anything.)

Don't want to have to apply multiple mega merges. :)

I'm not worried. As long as the conversion can be done with a tool on the push of a button, the whole thing isn't a big deal.

Plan A is to do the conversion in a moment when there are no PRs.

One of several possible plans B is to shrug shoulders, draw a deep breath, do the conversion on the main branch and also on the PR branch, catch the delta in a patchfile, and get the PR branch going afresh from the main branch's head via the patchfile. If there's a problem, I'm willing to offer help.

I took a closer look.

Please add

# See https://clang.llvm.org/docs/ClangFormatStyleOptions.html

at the top of the file, so people know where to find the documentation.

I think the funny comma thing is repaired by

BreakConstructorInitializers: AfterColon

The include sorting is

IncludeBlocks:   Regroup

together with

SortIncludes: true

I'm also a bit afraid the clang-format would ruin our documentation comments unless we say

ReflowComments:  false

In the past, we had a mixture of different line endings, partly in the same file. To not have that happen again:

LineEnding: LF

For all changes I would like to see, including less important ones, run the following through patch -p1

diff --git a/.clang-format b/.clang-format
index f258bb3d..162a4081 100644
--- a/.clang-format
+++ b/.clang-format
@@ -1,3 +1,5 @@
+# See https://clang.llvm.org/docs/ClangFormatStyleOptions.html
+
 Language:        Cpp
 # BasedOnStyle:  WebKit
 AccessModifierOffset: -4
@@ -45,7 +47,7 @@ AllowAllArgumentsOnNextLine: false
 AllowAllParametersOfDeclarationOnNextLine: false
 AllowBreakBeforeNoexceptSpecifier: Never
 AllowShortBlocksOnASingleLine: Empty
-AllowShortCaseLabelsOnASingleLine: false
+AllowShortCaseLabelsOnASingleLine: true
 AllowShortCompoundRequirementOnASingleLine: true
 AllowShortEnumsOnASingleLine: true
 AllowShortFunctionsOnASingleLine: InlineOnly
@@ -58,7 +60,7 @@ AttributeMacros:
   - __capability
 BinPackArguments: false
 BinPackParameters: false
-BitFieldColonSpacing: Both
+BitFieldColonSpacing: After
 BraceWrapping:
   AfterCaseLabel:  true
   AfterClass:      true
@@ -86,8 +88,8 @@ BreakBeforeBinaryOperators: All
 BreakBeforeConceptDeclarations: Always
 BreakBeforeBraces: Custom
 BreakBeforeInlineASMColon: OnlyMultiline
-BreakBeforeTernaryOperators: true
-BreakConstructorInitializers: BeforeComma
+BreakBeforeTernaryOperators: false
+BreakConstructorInitializers: AfterColon
 BreakInheritanceList: BeforeColon
 BreakStringLiterals: true
 ColumnLimit:     100
@@ -100,15 +102,16 @@ DerivePointerAlignment: false
 DisableFormat:   false
 EmptyLineAfterAccessModifier: Never
 EmptyLineBeforeAccessModifier: LogicalBlock
-ExperimentalAutoDetectBinPacking: false
-FixNamespaceComments: false
+# The doc recommends to not use this (yet):
+# ExperimentalAutoDetectBinPacking: false
+FixNamespaceComments: true
 ForEachMacros:
   - foreach
   - Q_FOREACH
   - BOOST_FOREACH
 IfMacros:
   - KJ_IF_MAYBE
-IncludeBlocks:   Preserve
+IncludeBlocks:   Regroup
 IncludeCategories:
   - Regex:           '^<.*>'
     Priority:        1
@@ -132,7 +135,7 @@ IndentAccessModifiers: false
 IndentCaseBlocks: false
 IndentCaseLabels: false
 IndentExternBlock: AfterExternBlock
-IndentGotoLabels: true
+IndentGotoLabels: false
 IndentPPDirectives: None
 IndentRequiresClause: true
 IndentWidth:     4
@@ -144,23 +147,31 @@ IntegerLiteralSeparator:
   Binary:          4
   BinaryMinDigits: 5
   Decimal:         3
-  DecimalMinDigits: 4
+  DecimalMinDigits: 7
   Hex:             0
   HexMinDigits:    0
 JavaScriptQuotes: Leave
 JavaScriptWrapImports: true
+# KeepEmptyLines:
+#   AtEndOfFile: false
+#   AtStartOfFile: false
+#   AtStartOfBlock: true
 LambdaBodyIndentation: Signature
-LineEnding:      DeriveLF
+LineEnding: LF
 MacroBlockBegin: ''
 MacroBlockEnd:   ''
 MaxEmptyLinesToKeep: 2
 NamespaceIndentation: Inner
+# NumericLiteralCase:
+#   ExponentLetter: Lower
+#   HexDigit: Lower
+#   Prefix: Lower
 ObjCBinPackProtocolList: Auto
 ObjCBlockIndentWidth: 4
 ObjCBreakBeforeNestedBlockParam: true
 ObjCSpaceAfterProperty: true
 ObjCSpaceBeforeProtocolList: true
-PackConstructorInitializers: Never
+PackConstructorInitializers: NextLine
 PenaltyBreakAssignment: 2
 PenaltyBreakBeforeFirstCallParameter: 19
 PenaltyBreakComment: 300
@@ -176,16 +187,17 @@ PointerAlignment: Left
 PPIndentWidth:   -1
 QualifierAlignment: Leave
 ReferenceAlignment: Pointer
-ReflowComments:  true
+# Not sure how clever clang is with respect to doxygen comments.
+ReflowComments:  false
 RemoveBracesLLVM: false
 RemoveParentheses: Leave
 RemoveSemicolon: false
 RequiresClausePosition: OwnLine
 RequiresExpressionIndentation: OuterScope
-SeparateDefinitionBlocks: Leave
+SeparateDefinitionBlocks: Always
 ShortNamespaceLines: 1
 SkipMacroDefinitionBody: false
-SortIncludes:    Never
+SortIncludes: true
 SortJavaStaticImport: Before
 SortUsingDeclarations: LexicographicNumeric
 SpaceAfterCStyleCast: false

I prefer the

if (...) {
} else {
}

but its not of much importance, so we can have the braces your way. (Depending on what others say, if anything.)

That also works. Originally it was doing a single line if it could do it in a 80 char width, ie if(badabing){some really long code}else{some more code}

Ok, give that a whirl. Turns out there is a fix for the ReflowComments, but only if you have clang 19+, which I don't.
I think there was one other thing I did not change from @aknrdureegaesr on your request (it may have been the commented EmptyLines at end of file). Also, thanks for finding the DecimalMinDigits! Much better!

This can merge whenever.

I think there was one other thing I did not change from @aknrdureegaesr on your request (it may have been the commented EmptyLines at end of file).

I had suggested

IndentGotoLabels: false

to make goto labels stick out like a sore thumb.

But as we basically do not use goto, that does not matter much.

I rebased this, squashed the several commits into one, added a "." to the initial commit comment.

I took the source and re-formatted it via

clang-format-18 --Werror -i *.h *.hpp *.cpp

and confirmed everything still compiles and the resulting program still runs.

I pushed the rebased branch to our main branch.

One step further towards more consistent coding. Thanks, @wmiler !