Automated style linting for C source code

[jemc]

I've opened this issue to discuss adding automated style linting for the C source.

This was mentioned by @tokenrove in #1526 (comment).

Offhand, it's not a big deal, but it would be nice if there was a style lint and a suggested emacs setup for editing the C source. Maybe these exist and I missed them.

[jemc]

I'll copy my response here as well, for posterity and to kick off the conversation.

I don't deal a lot with automated style linting, as most projects I work heavily on have a style that's more subjective and difficult to automate for. For styles like that, I prefer to just work socially and pay attention to surrounding code to match style.

However, the C source for this project does have a very mechanical style, so I would definitely be open to someone adding a automated style linting tool configuration (for the C source only, I think). As long as it doesn't add any required dependencies for building the project, I think it should be okay.

Since I'm going to merge this PR, I'll open a ticket for the style linting question, mention you in it, and mark it for discussion on today's sync call to see if anyone is opposed to such an initiative.

[jemc]

In the sync call, no one was opposed to introducing some automatic style linting to the C style, provided that it doesn't add any additional requirements to building Pony (essentially, that linting is a separate action).

So if anyone wants to do a PR to introduce C style linting to match our current C style, it would be welcome.

[SeanTAllen]

Does anyone have a preference on this?

I'm thinking GNU ident.

https://www.gnu.org/software/indent/

[tokenrove]

Sorry, I meant to write up some details about this since I have some experience with it. There are a variety of tools I personally prefer over indent, but the easiest and most widespread is clang-format. https://zed0.co.uk/clang-format-configurator/

The tricky thing is detecting style violations without aggressively reformatting any existing code or introducing outright barbarisms.

I seem to recall astyle had a few suitable options in this respect.

[SeanTAllen]

@tokenrove Sylvan says he likes that clang formatter. So I would say this is now "ready for work" with a specific tool in mind.

[tokenrove]

I've been working on this a little. Below is the beginnings of a .clang-format file to match the current source code. I'm planning to add a git commit hook that checks any .c, .h, and .cc files in the diff to be committed with clang-format-diff. If you'd like me to open a PR just adding the .clang-format file, or have suggested changes, let me know. I'm trying to have the smallest set of rules that accept most recent diffs that don't have obvious style deviations.

---
AlignAfterOpenBracket: DontAlign
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
BinPackArguments: 'true'
BinPackParameters: 'true'
BreakBeforeBraces: Allman
ColumnLimit: '80'
ContinuationIndentWidth: '2'
IndentWidth: '2'
MaxEmptyLinesToKeep: '2'
PointerAlignment: Left
SpaceBeforeParens: Never
UseTab: Never

...