Clang format proposal v5

[roligugus]

Continuation of #5186

Make sure these boxes are signed before submitting your Pull Request -- thank you.

• I have read the contributing guide lines at https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Contributing
• I have signed the Open Information Security Foundation contribution agreement at https://suricata-ids.org/about/contribution-agreement/
• I have updated the developer guide (in doc/devguide/) to reflect the changes made (if applicable)

Link to redmine ticket:
https://redmine.openinfosecfoundation.org/issues/3736

Describe changes:

• Updated with review comments. Lots of small formatting adjustment, e.g.
• 100 chars line length @victorjulien
• 4 chars indentation for variable definitions @jasonish
• Unify "foreach" macro formatting including TAILQ_FOREACH and all others I found. @jasonish
• Added link to documentation in .clang-format @jasonish

Main other changes are...

• Error in case of wrong formatting as per discussion
• Ignoring the "merge commit" for merges to OISF repo to not complain about wrong formatting on newer commits on master
• Using minimal .clang-format file
• Removed sample file as well
• Removed make targets, updated devguide to refer to helper script instead

Wrong Formatting is an Error

As per #5186 (comment), formatting produces a github action error. This will provide a better visual and show the formatting-check action as failed in your pull request...

Example formatting-check action error: https://github.com/OISF/suricata/runs/914986617?check_suite_focus=true

One can chose which actions must pass in "Branch prediction Rules" in the repo settings. You could require all actions but the "formatting-check" to pass to still allow merging even if formatting is not correct:

it seems one can pick which status checks that have to pass in your "Branch Protection Rules", see https://docs.github.com/en/github/administering-a-repository/enabling-required-status-checks

So as long as you don't require the formatting-check to pass, you can merge pull requests.

Hence, I'd recommend the formatting-check to error out in case of wrong formatting problems and not pick it as a required "status check" for merging purposes. That way, you'd see the red failure indication in the pull request, yet your merging is not blocked. I.e. it's up to you as maintainers to decide whether to request a formatting change on the pull request or merge something in anyways.

[roligugus]

The doc diff can be a pain to read.

See https://github.com/roligugus/suricata/blob/clang-format-proposal-v5/doc/devguide/codebase/code-style.rst for the formatted doc.

[victorjulien]

clang-format file commit says "DO NOT MERGE AS IS."

Is that still correct?

[roligugus]

clang-format file commit says "DO NOT MERGE AS IS."

Is that still correct?

No, argh! I forgot to update the commit message.

Should I fix the commit and repush this, or wait for feedback and then fix in a potential v6?

[victorjulien]

Any idea what I'm missing here?

[roligugus]

Any idea what I'm missing here?

Yeah, that's the messy ubuntu clang versioning... Do this
git clang-format-9 --binary clang-format-9 HEAD^

Fyi, git clang-format-9 ... will call the git-clang-format-9 script which will use the clang-format binary by default, but in in ubuntu's case should use the clang-format-9 binary.

Btw, you could also configure a different clang-format version to use if not specified - just don't forget to change this if you ever switch to a different clang-format version: git config clangformat.binary "clang-format-9" or git config --global clangformat.binary "clang-format-9" which will allow you to go back to git clang-format-9 HEAD^

Or simply use the helper script ;)

[victorjulien]

Merged in #5349, thanks a lot @roligugus ! This was a much heavier lift than I would have thought beforehand. Really appreciate the work you've put into this.

Now lets see how well it will fit into our workflows :)