Hello,
it was discussed during the last irc devel meeting and everyone there agreed to use clang-format to format the source code:
- https://clang.llvm.org/docs/ClangFormat.html
Is any developer (maybe not present during the irc devel meeting) opposing this?
It is not going to be all at once, because some of the structures and initialization of them may be preferred to be kept with a custom format for being easier to read -- to have a section in the file not formatted, it has to be enclosed in between comments:
/* clang-format off */
...
/* clang-format o. */
But for the rest of the code (i.e., functions) I think it will be better to agree on a format and try to use it. The clang-formatting should be done when one needs to update code in some files.
Over the years, developers come and go, having each one with a custom formatting style is hard to maintain properly in long term. There are modules that do not indent coherently code inside blocks, using a mixture, more or less no style. This makes it hard for other developers to review in case of reported issues, but also for new comers to get familiar with the code.
In the source tree there is already a .clang-format file which defines the options for formatting.
It was used by me and other developers already -- I did it mainly in my modules or those components that do not have an active maintainer. But I plan to do it also on the components that have currently a maintainer at the moment I need to work on that code (e.g., fix some issue or export functions to kemi framework).
My process of clang-formatting a module is like:
- edit the files to add clang-format off/on comments around the parts I want to preserve as they are (typically mod exports -- params, functions, kemi -- and intialization of structures that are aligned to a specific indentation that makes it easier to read).
- run: clang-format -i src/modules/modname/*.{c,h}
- commit with these changes, no new feature or bug fix must be done in the same commit (can be combined with removing the history comments)
If one wants different options inside .clang-format, please propose and let's discuss which one is preferred by the majority of the current developers.
If no one shows anything against in a matter of few days, it will be considered accepted (after all, one can re-indent on own style if the rule is not accepted or overturned).
Cheers, Daniel
Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin Mierla:
it was discussed during the last irc devel meeting and everyone there agreed to use clang-format to format the source code:
Is any developer (maybe not present during the irc devel meeting) opposing this? [explanation of motivation]
Hello Daniel,
I think there is only (small) downside of a thorough re-formatting of the code like this: It makes manual bug triage with git blame more difficult, as git blame shows only the last commit in a line.
Therefore its important that this changes are applied as one dedicated commit per module, not mixed with other functional changes (exactly as you proposed).
The advantages of a consistent style in all modules are much greater than this downside, I have nothing against this change.
If no one shows anything against in a matter of few days, it will be considered accepted (after all, one can re-indent on own style if the rule is not accepted or overturned).
Best regards,
Henning
Hello Henning,
indeed, git blame is not going to show directly the original author... as I wanted to see if there is a solution for this, I found:
- https://blog.andrewray.me/a-better-git-blame/
and actually a comment there seems to be a decent solution to go back in the history of the commits to find the author, pasting it here:
Just use `git gui blame -- path/to/file.ext` followed by right click
and `Do full copy detection`.
Scroll to line you want to investigate and see the commit message. If
it looks like it's not the commit
you're interested in, right click the line you're really interested in
and select `Blame parent commit`.
Doing it this way allows you to find the whole history of that line
even if it came from another file.
Also, we lost the direct seeing of the commit log for some files when we relocated code for 5.0 release, therefore now git log needs to be used --follow flag if one wants to track back to the origin. I added aliases in my gitconfig to make it shorted to work with:
logf = log --follow logfp = log -p --follow logpf = log -p --follow
Cheers, Daniel
On 24.11.17 08:39, Henning Westerholt wrote:
Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin Mierla:
it was discussed during the last irc devel meeting and everyone there agreed to use clang-format to format the source code:
Is any developer (maybe not present during the irc devel meeting) opposing this? [explanation of motivation]
Hello Daniel,
I think there is only (small) downside of a thorough re-formatting of the code like this: It makes manual bug triage with git blame more difficult, as git blame shows only the last commit in a line.
Therefore its important that this changes are applied as one dedicated commit per module, not mixed with other functional changes (exactly as you proposed).
The advantages of a consistent style in all modules are much greater than this downside, I have nothing against this change.
If no one shows anything against in a matter of few days, it will be considered accepted (after all, one can re-indent on own style if the rule is not accepted or overturned).
Best regards,
Henning
Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin Mierla:
it was discussed during the last irc devel meeting and everyone there agreed to use clang-format to format the source code:
Does anyone have emacs c-mode-hook for this or am I too old school when I still use emacs?
-- Juha
On 24.11.17 09:12, Juha Heinanen wrote:
Am Donnerstag, 23. November 2017, 17:20:48 CET schrieb Daniel-Constantin Mierla:
it was discussed during the last irc devel meeting and everyone there agreed to use clang-format to format the source code:
Does anyone have emacs c-mode-hook for this or am I too old school when I still use emacs?
Not using clang myself, but found:
- https://github.com/sonatard/clang-format
Then this blog looks to be recent enough:
- https://eklitzke.org/smarter-emacs-clang-format
Cheers, Daniel
-
Daniel-Constantin Mierla -
Henning Westerholt -
Juha Heinanen