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

47 lines
1.4 KiB
Plaintext
Raw Normal View History

.gitlab-ci.yml: add clang-format rules and pipeline Fixes #950 `.gitlab/search-common-ancestor.sh`'s original authors are Philip Withnall and Frederic Martinsons. (Jehan/reviewer's note: script further improved by Asalle)
2022-01-20 04:44:45 +08:00
# For more information, see:
#
# https://clang.llvm.org/docs/ClangFormat.html
# https://clang.llvm.org/docs/ClangFormatStyleOptions.html
#
---
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…
2022-03-15 01:01:54 +08:00
BasedOnStyle: GNU
.gitlab-ci.yml: add clang-format rules and pipeline Fixes #950 `.gitlab/search-common-ancestor.sh`'s original authors are Philip Withnall and Frederic Martinsons. (Jehan/reviewer's note: script further improved by Asalle)
2022-01-20 04:44:45 +08:00
AlignAfterOpenBracket: Align
clang-format: improve according to our coding style. - Align macro values. - Align backslashes to escape newlines. - Added explicit PointerAlignment though this one seems unneeded. - Increase the column limit (even though 80 is really the official one) and add some penalty on breaking on very unexpected places, such as around assignments or on first parameters in calls/declaration. We want short lines but this is more of a soft rule which should not override sensible line breaking rules. - Group some rules and reorder rule names alphabetically within groups.
2022-01-20 06:17:23 +08:00
AlignArrayOfStructures: Left
.gitlab-ci.yml: add clang-format rules and pipeline Fixes #950 `.gitlab/search-common-ancestor.sh`'s original authors are Philip Withnall and Frederic Martinsons. (Jehan/reviewer's note: script further improved by Asalle)
2022-01-20 04:44:45 +08:00
AlignConsecutiveAssignments: Consecutive
AlignConsecutiveDeclarations: Consecutive
clang-format: improve according to our coding style. - Align macro values. - Align backslashes to escape newlines. - Added explicit PointerAlignment though this one seems unneeded. - Increase the column limit (even though 80 is really the official one) and add some penalty on breaking on very unexpected places, such as around assignments or on first parameters in calls/declaration. We want short lines but this is more of a soft rule which should not override sensible line breaking rules. - Group some rules and reorder rule names alphabetically within groups.
2022-01-20 06:17:23 +08:00
AlignConsecutiveMacros: Consecutive
AlignEscapedNewlines: Left
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…
2022-03-15 01:01:54 +08:00
AllowAllParametersOfDeclarationOnNextLine: false
.gitlab-ci.yml: add clang-format rules and pipeline Fixes #950 `.gitlab/search-common-ancestor.sh`'s original authors are Philip Withnall and Frederic Martinsons. (Jehan/reviewer's note: script further improved by Asalle)
2022-01-20 04:44:45 +08:00
AlwaysBreakAfterReturnType: AllDefinitions
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…
2022-03-15 01:01:54 +08:00
BinPackParameters: false
clang-format: improve according to our coding style. - Align macro values. - Align backslashes to escape newlines. - Added explicit PointerAlignment though this one seems unneeded. - Increase the column limit (even though 80 is really the official one) and add some penalty on breaking on very unexpected places, such as around assignments or on first parameters in calls/declaration. We want short lines but this is more of a soft rule which should not override sensible line breaking rules. - Group some rules and reorder rule names alphabetically within groups.
2022-01-20 06:17:23 +08:00
BreakBeforeBraces: GNU
.gitlab-ci.yml: add clang-format rules and pipeline Fixes #950 `.gitlab/search-common-ancestor.sh`'s original authors are Philip Withnall and Frederic Martinsons. (Jehan/reviewer's note: script further improved by Asalle)
2022-01-20 04:44:45 +08:00
IndentWidth: 2
clang-format: improve according to our coding style. - Align macro values. - Align backslashes to escape newlines. - Added explicit PointerAlignment though this one seems unneeded. - Increase the column limit (even though 80 is really the official one) and add some penalty on breaking on very unexpected places, such as around assignments or on first parameters in calls/declaration. We want short lines but this is more of a soft rule which should not override sensible line breaking rules. - Group some rules and reorder rule names alphabetically within groups.
2022-01-20 06:17:23 +08:00
PointerAlignment: Right
UseTab: Never
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…
2022-03-15 01:01:54 +08:00
SpaceBeforeParens: Always
SpaceAfterLogicalNot: true
SpaceAfterCStyleCast: true
clang-format: improve according to our coding style. - Align macro values. - Align backslashes to escape newlines. - Added explicit PointerAlignment though this one seems unneeded. - Increase the column limit (even though 80 is really the official one) and add some penalty on breaking on very unexpected places, such as around assignments or on first parameters in calls/declaration. We want short lines but this is more of a soft rule which should not override sensible line breaking rules. - Group some rules and reorder rule names alphabetically within groups.
2022-01-20 06:17:23 +08:00
# 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
# higher limit. Then let's put some biggish penalties on breaking on
# assignment, or parentheses, or other similar cases. Actually with such
# 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
# over-nested block case).
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…
2022-03-15 01:01:54 +08:00
ColumnLimit: 80
PenaltyBreakAssignment: 60
PenaltyBreakBeforeFirstCallParameter: 100
PenaltyBreakString: 60
clang-format: improve according to our coding style. - Align macro values. - Align backslashes to escape newlines. - Added explicit PointerAlignment though this one seems unneeded. - Increase the column limit (even though 80 is really the official one) and add some penalty on breaking on very unexpected places, such as around assignments or on first parameters in calls/declaration. We want short lines but this is more of a soft rule which should not override sensible line breaking rules. - Group some rules and reorder rule names alphabetically within groups.
2022-01-20 06:17:23 +08:00
# Uncomment this when we start using clang-format 14 in the CI.
# PenaltyBreakOpenParenthesis: 40
PenaltyExcessCharacter: 1
# Strings are more often longer by usage, so let's give these slightly
# more space to breath.
PenaltyBreakString: 60
PenaltyReturnTypeOnItsOwnLine: 50