dnrops
/
gimp
mirror of https://github.com/GNOME/gimp.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

clang-format: update. 

I tested it against various merge requests and the more I go, the more I
wonder if it will ever be *really* useful. It detects so many false
positive of totally acceptable code. I tweak the style rules, improve
some things but then make other things worse.

Actually the logic of having one "best" case with the penalty system is
flawed IMO. We should really have rules of what is acceptable and should
not trigger changes vs. what is not acceptable styling.
For instance what such a system cannot detect is when we organize some
things on purpose, for instance for semantic reasons. If it's just "best
rule" based, it cannot work, but with an "acceptable style" logic, the
on-purpose organization of code will just pass as long as it doesn't
break the coding style.

Anyway let's see…
This commit is contained in:
Jehan 2022-03-14 18:01:54 +01:00
parent cab09cd1a6
commit 2d0ece6a03
1 changed files with 12 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
.clang-format
View File

@ -5,6 +5,8 @@
# #
--- ---
BasedOnStyle: GNU
AlignAfterOpenBracket: Align AlignAfterOpenBracket: Align
AlignArrayOfStructures: Left AlignArrayOfStructures: Left
AlignConsecutiveAssignments: Consecutive AlignConsecutiveAssignments: Consecutive
@ -12,13 +14,18 @@ AlignConsecutiveDeclarations: Consecutive
AlignConsecutiveMacros: Consecutive AlignConsecutiveMacros: Consecutive
AlignEscapedNewlines: Left AlignEscapedNewlines: Left
AllowAllParametersOfDeclarationOnNextLine: false
AlwaysBreakAfterReturnType: AllDefinitions AlwaysBreakAfterReturnType: AllDefinitions
BinPackParameters: false
BreakBeforeBraces: GNU BreakBeforeBraces: GNU
IndentWidth: 2 IndentWidth: 2
SpaceBeforeParens: Always
PointerAlignment: Right PointerAlignment: Right
UseTab: Never UseTab: Never
SpaceBeforeParens: Always
SpaceAfterLogicalNot: true
SpaceAfterCStyleCast: true
# Our column limit is more around 80 characters but we want to avoid # Our column limit is more around 80 characters but we want to avoid
# this rule to be over-agressive. So for clang-format, let's use a # this rule to be over-agressive. So for clang-format, let's use a
# higher limit. Then let's put some biggish penalties on breaking on # higher limit. Then let's put some biggish penalties on breaking on
@ -26,9 +33,10 @@ UseTab: Never
# limits, if clang-format really ends up re-formatting, there might be # limits, if clang-format really ends up re-formatting, there might be
# something better to do code-wise (i.e. we might be in an akwardly # something better to do code-wise (i.e. we might be in an akwardly
# over-nested block case). # over-nested block case).
ColumnLimit: 100 ColumnLimit: 80
PenaltyBreakAssignment: 40 PenaltyBreakAssignment: 60
PenaltyBreakBeforeFirstCallParameter: 40 PenaltyBreakBeforeFirstCallParameter: 100
PenaltyBreakString: 60
# Uncomment this when we start using clang-format 14 in the CI. # Uncomment this when we start using clang-format 14 in the CI.
# PenaltyBreakOpenParenthesis: 40 # PenaltyBreakOpenParenthesis: 40
PenaltyExcessCharacter: 1 PenaltyExcessCharacter: 1