ci: add .clang-format and PR format-check step#139
Conversation
Add a .clang-format configuration that captures the existing Open1722
code style:
- 4-space indent, no tabs
- Linux brace style (function braces on a new line, control-structure
braces on the same line as the keyword)
- case labels at switch indent level (IndentCaseLabels: false)
- includes are not reordered (SortIncludes: Never)
Add a 'format' job to the GitHub Actions workflow that runs only on
pull requests. It installs clang-format, collects the C/H files
changed in the PR (via git diff against the PR base), and calls
clang-format --dry-run --Werror on them. Existing files not touched
by a PR are left unaffected so the CI passes immediately without
requiring a big reformatting sweep.
Signed-off-by: Matt Jones <47545907+SoundMatt@users.noreply.github.com>
|
Friendly ping — this PR has been open for 3+ weeks with no review activity. The change is self-contained (adds a |
|
Hi Matt, Sorry for keeping you waiting. Thanks for having a look at this issues. I'll try to review your PR within this week. Regards |
|
Hi Matt, I like the PR and would like to integrate it. The only issue I have is, that the formatting check is assigned to the Build Open1722 workflow (see image below) even though it has nothing to do with the build itself. My suggestion would be to combine the formatting related checks, that is:
under one common workflow. What do you think? Regards 
|
2 participants
Closes #30
Summary
.clang-format— captures the style already used in the codebase:BreakBeforeBraces: Linux(function braces on a new line, control-structure braces on the same line)IndentCaseLabels: false(case labels aligned with enclosing switch)SortIncludes: Never(existing include ordering is intentional and must not be disrupted)CI
formatjob — runs only on pull requests; installsclang-format, collects C/H files changed relative to the PR base (git diff --name-only ... | grep -E '\.(c|h)$'), and runsclang-format --dry-run --Werroron them.Existing files that a PR does not touch are not checked, so the CI passes immediately without requiring a large reformatting sweep. New or modified files must conform to the style going forward.
Why a PR-scoped check?
A whole-tree format check would fail instantly because the existing code has minor style drift (e.g. mixed spacing around
*in pointer declarations). A PR-scoped check enforces style on new contributions without blocking existing work.