Yes, I know... I know... I said I had no intention of doing any kind of formatting. But this weekend I started looking at clang-format and put together a config file "roughly" similar to the existing codebase. I haven't decided for sure I want to do this, but I was hoping to get some feedback and discussion.

But first: I beg, please restrain yourself from turning this into a "let's redesign the Mutt format standards from scratch" discussion. I'm looking for targeted discussion on the merits or potential issues with these settings and how they can reflect the general current "standards", such as there are.

If you try it out, note that there are two files that shouldn't be entirely reformatted. In init.h, the config options array is carefully formatted to be read by the documentation generator, so that whole long list shouldn't be touched. The same in functions.h with the various maps.

Also, reformatting in a few instances separates L10N comments from the marked parameter. I've noted the places that need to be cleaned up after my trial. If we go ahead I'll do that again.

My laptop is running Arch, which has clang-format version 21.1.8. It seems there is some churn on the options and what appropriate values are available across versions. For instance, SpaceInEmptyBraces seems to be available starting at 22.

Now, after that overlong intro... here are some points in the config I want to emphasize for potential discussion (or limit discussion on):

ColumnLimit: 80
PenaltyExcessCharacter: 5

The intent here is to have a standard 80 column limit but not to be draconian about it. The formatter is free to go longer, if it helps with other formatting trade-offs. I don't know much about penalties. If you have experience and think "5" is too low or too high, please let me know. Or if there is a better way to set a limit that is flexible.

IndentWidth: 2

This has been the standard in the Mutt code for a long time, and I'm not flexible on this one.

SpaceAfterCStyleCast: true

I think this is generally the case in the mutt code but it's not uniform. I don't insist on this one. Definitely open for discussion.

IndentGotoLabels: false

There are both styles in the code.  Also definitely open for discussion.

KeepEmptyLines:
 AtEndOfFile: false
 AtStartOfBlock: false
 AtStartOfFile: false

It seems like a good idea? Please say something if in your experience this isn't.

AlignAfterOpenBracket: Align

This is generally the case in the Mutt code. I think overall it looks nice, but there is the trade-off with long function names and/or deep indention where parameters start to not all fit within 80 columns.

SpaceBeforeParens: Always

I know this one is controversial. It took me a while to get used to the function definition and declaration style in Mutt. It's not very standard, so I'd appreciate some other viewpoints, but let's not get bogged down on this one, okay? I'm most likely not up for changing it unless I hear old-time devs chime-in against it too.

Anything else I missed or you see that's a bad idea? Please speak up. Thank you.

Anyway here's the config I tried this morning:

AlignAfterOpenBracket: Align
AlignArrayOfStructures: Left
AlignConsecutiveAssignments: None
AlignConsecutiveBitFields: None
AlignConsecutiveDeclarations: None
AlignConsecutiveMacros: Consecutive
AlignEscapedNewlines: Left
AlignOperands: Align
AlignTrailingComments:
  Kind: Leave
AllowAllArgumentsOnNextLine: false
AllowAllParametersOfDeclarationOnNextLine: false
AllowShortBlocksOnASingleLine: Never
AllowShortCaseExpressionOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortEnumsOnASingleLine: false
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: Never
AllowShortLoopsOnASingleLine: false
AlwaysBreakBeforeMultilineStrings: false
BinPackArguments: true
BinPackParameters: true
BitFieldColonSpacing: Both
BreakAdjacentStringLiterals: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Allman
BreakBeforeTernaryOperators: false
BreakBinaryOperations: Never
BreakFunctionDefinitionParameters: false
BreakStringLiterals: false
ColumnLimit: 80
DerivePointerAlignment: false
IncludeBlocks: Preserve
IndentCaseBlocks: false
IndentCaseLabels: true
IndentGotoLabels: false
IndentPPDirectives: AfterHash
IndentWidth: 2
IndentWrappedFunctionNames: false
InsertBraces: false
InsertNewlineAtEOF: true
KeepEmptyLines:
  AtEndOfFile: false
  AtStartOfBlock: false
  AtStartOfFile: false
Language: C
LineEnding: LF
MaxEmptyLinesToKeep: 1
PenaltyExcessCharacter: 5
PPIndentWidth: 1
PointerAlignment: Right
QualifierAlignment: Leave
ReflowComments: Never
RemoveEmptyLinesInUnwrappedLines: true
RemoveParentheses: Leave
RemoveSemicolon: false
SkipMacroDefinitionBody: true
SortIncludes:
  Enabled: false
SpaceAfterCStyleCast: true
SpaceAfterLogicalNot: false
SpaceAroundPointerQualifiers: Default
SpaceBeforeAssignmentOperators: true
SpaceBeforeCaseColon: false
SpaceBeforeParens: Always
SpaceBeforeSquareBrackets: false
# SpaceInEmptyBraces: true
SpacesInParens: Never
SpacesInSquareBrackets: false
TabWidth: 8
UseTab: Never

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

Attachment: signature.asc
Description: PGP signature

Reply via email to