Introduce clang-format #1464
Introduce clang-format #1464
Conversation
Remove trailing whitespaces, except for the generated wayland code.
dunst has a mix of indentation styles. Try to improve it by making it consistent in files with mixed tab/space indentation styles. While this also changes the generated manpages slightly, it makes it more consistent accross the man page and probably won't be noticed by the reader.
Add an .editorconfig file to automatically configure supported editors. This file was generated merely based on the existent styles and the warnings caused while checking the code with the editorconfig-checker tool. As the editorconfig checker tool generates false positives when an indentation is adjusted to match multiline arguments or similar aesthetic adaptions, the corresponding check was disabled. This will miss wrong indentation sizes (e.g. 4 instead of 8 spaces).
Format all source files with clang-format using the following comamnd: clang-format -i **/*.c *.c **/*.h *.h
|
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #1464 +/- ##
==========================================
- Coverage 65.47% 65.25% -0.22%
==========================================
Files 50 50
Lines 8923 9038 +115
Branches 1044 1048 +4
==========================================
+ Hits 5842 5898 +56
- Misses 3081 3140 +59
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Is this alongside the editorconfig pr or supersedes it? The config seems sensible but my problem is that such a big commit would dirty the git history |
no, this is alongside the editorconfig PR. The PR is just included to see, if the formatting trips up something in the editorconfig checker. The main purpose of the editorconfig is to avoid having to manually adjust the editor each time (use tabs/spaces, indention width, ...). It's like vim modelines, but supported by much more editors by default. Checking the editorconfig is just to prevent some basic stuff. clang-format on the other hand precisely defines how C/C++ files should be formatted and therefore removes manual formatting and potential discussion entirely.
You can partially work around with a |
|
General thoughts how to proceed? As described above, there are multiple ways to handle the potential reformatting. And the still missing Github CI Action in this PR would depend on this choice. I also wouldn't mind if this PR is closed, but in this case I want to avoid the effort of implementing these CI Actions. |
|
For now let's use the editorconfig. I am not opposed to using autoformat but I have some things to still think through. Also since we are going to reformat everything we may decide to use a slightly different style. |
Automatically format the code with clang-format to always have a consistent style.
Options used:
void foo() {}, but notvoid foo() { bar(); })case A: return foo;)@bynect @fwsmit Would like to hear your thoughts about this style. Some additional desires or maybe remove some of the options?
Also feel free to point out potential ways, where the formatting really breaks the understanding. If they cannot be formatted in a better way, then they always can be excluded using comments.
TODO myself: Add some github action to check the code matches the formatting.