[Grep-devel] [PATCH] Adding .clang-format - ClangFormat config for automated code style

[Sebastian Jennen]

Hello grep team,

are you interested in applying a consistent automated coding style to 
the grep
project?

In many other OSS projects this is done by using ClangFormat.
ClangFormat is a CLI-tool which uses the clang-tokenizer to tokenize the 
code
and recombine the code again by applying a certain specified code style.
The code style can be defined in a .clang-format file and can be tweaked to
apply to almost any "common" style. In comparison to astyle, ClangFormat 
styles
more aggressively and has more configuration options.
More information here: https://clang.llvm.org/docs/ClangFormat.html

ClangFormat is present in most GNU/Linux based Distros (Debian, Fedora, 
Ubuntu,
...). Current common version in recent Distro images are 5.0.0 - 6.0.0.
The versions of ClangFormat are not backward or forward compatible, but the
style format is forward compatible and the style only changes slightly in
newer versions. Also some package managers keep different versions of
ClangFormat to be installed at any time.

I wrote a sniffer which can find the "closest" config to an existing 
code base.

The following .clang-format matches to 91.52%, meaning that 91.52% of 
the lines
of the source code are left untouched (tested with latest commit 30e666 and
clang-format-6.0, if neccessary older versions can deliver similarly good
results).

In order to test this, you can apply the patch in this email, which puts the
contents to .clang-format file in project root.

You will need to install clang-format (eg.: apt-get install 
clang-format-6.0).
Then you can run the following command in a terminal from the project 
root to
apply the code format:

```
for i in {tests,src,lib}/*.{h,c,hpp,cpp}; \
    do clang-format-6.0 -i -style=file $i; done
```

clang-format is non destructive and does not change the semantics of the 
code.
I double checked by compiling and running the grep code: works fine.
./grep -ir "grep" .

Examples for automatic changes are:

pointer alignment inconsistencies (project uses mostly right aligned 
pointers):
-  struct re_pattern_buffer* patterns;
+  struct re_pattern_buffer *patterns;

line width expanding to ColumnLimit (detected line width of 80 chars):
-          start = re_search (&dc->patterns[i], beg, end - beg - 1,
-                             ptr - beg, end - ptr - 1, &dc->regs);
+          start = re_search (&dc->patterns[i], beg, end - beg - 1, ptr 
- beg,
+                             end - ptr - 1, &dc->regs);

indentation fixes:
-        if (best_match < end)
...
+      if (best_match < end)
...

various braking and non braking rules
-               | (IGNORE_DUPLICATE_BRANCH_WARNING
-                  (binary ? O_BINARY : 0))
+               | (IGNORE_DUPLICATE_BRANCH_WARNING (binary ? O_BINARY : 0))

and many more...

Please let me know, what you think of it.

Best Regards,
Sebastian Jennen

---
diff --git a/.clang-format b/.clang-format
new file mode 100644
index 0000000..75241d2
--- /dev/null
+++ b/.clang-format
@@ -0,0 +1,88 @@
+---
+TabWidth: 4
+UseTab: Never
+AccessModifierOffset: -4
+AlignAfterOpenBracket: Align
+AlignConsecutiveAssignments: false
+AlignConsecutiveDeclarations: false
+AlignEscapedNewlines: DontAlign
+AlignOperands: true
+AlignTrailingComments: false
+AllowAllParametersOfDeclarationOnNextLine: true
+AllowShortBlocksOnASingleLine: true
+AllowShortCaseLabelsOnASingleLine: false
+AllowShortFunctionsOnASingleLine: None
+AllowShortIfStatementsOnASingleLine: false
+AllowShortLoopsOnASingleLine: false
+AlwaysBreakAfterReturnType: AllDefinitions
+AlwaysBreakBeforeMultilineStrings: true
+AlwaysBreakTemplateDeclarations: true
+BinPackArguments: true
+BinPackParameters: true
+BreakAfterJavaFieldAnnotations: true
+BreakBeforeBinaryOperators: NonAssignment
+BreakBeforeBraces: Custom
+BreakBeforeInheritanceComma: true
+BreakBeforeTernaryOperators: true
+BreakConstructorInitializers: BeforeColon
+BreakStringLiterals: true
+ColumnLimit: 80
+CompactNamespaces: true
+ConstructorInitializerAllOnOneLineOrOnePerLine: true
+ConstructorInitializerIndentWidth: 0
+ContinuationIndentWidth: 0
+Cpp11BracedListStyle: false
+ExperimentalAutoDetectBinPacking: true
+FixNamespaceComments: true
+ForEachMacros:
+IncludeBlocks: Preserve
+IndentCaseLabels: false
+IndentPPDirectives: AfterHash
+IndentWidth: 2
+IndentWrappedFunctionNames: true
+JavaScriptQuotes: Leave
+KeepEmptyLinesAtTheStartOfBlocks: true
+MaxEmptyLinesToKeep: 2
+NamespaceIndentation: None
+ObjCBlockIndentWidth: 2
+ObjCSpaceAfterProperty: true
+ObjCSpaceBeforeProtocolList: true
+PenaltyBreakAssignment: 50
+PenaltyBreakBeforeFirstCallParameter: 12
+PenaltyBreakComment: 80
+PenaltyBreakFirstLessLess: 0
+PenaltyBreakString: 0
+PenaltyExcessCharacter: 100
+PenaltyReturnTypeOnItsOwnLine: 20
+PointerAlignment: Right
+SortIncludes: false
+SortUsingDeclarations: true
+SpaceAfterCStyleCast: true
+SpaceAfterTemplateKeyword: true
+SpaceBeforeAssignmentOperators: true
+SpaceBeforeParens: Always
+SpaceInEmptyParentheses: false
+SpacesBeforeTrailingComments: 1
+SpacesInAngles: true
+SpacesInCStyleCastParentheses: false
+SpacesInContainerLiterals: true
+SpacesInParentheses: false
+SpacesInSquareBrackets: false
+Standard: Cpp03
+BraceWrapping:
+  AfterClass: false
+  AfterControlStatement: true
+  AfterEnum: false
+  AfterFunction: true
+  AfterNamespace: false
+  AfterObjCDeclaration: false
+  AfterStruct: true
+  AfterUnion: false
+  BeforeCatch: false
+  BeforeElse: true
+  IndentBraces: true
+  AfterExternBlock: false
+  SplitEmptyFunction: false
+  SplitEmptyRecord: false
+  SplitEmptyNamespace: false
+---