Formating tools
psychocoderHPC opened this issue · comments
Here you can add tools those help to format the source code.
The goal is that we find a formatting tool to automate the formation.
tool: clang format
Online tool to configure the style: https://zed0.co.uk/clang-format-configurator/#
pull request: #32
Let me bring up this discussion and push the usage of #32.
We also have a style file suggestion in
- alpaka alpaka-group/alpaka#781
- and a derived style in mallocMC alpaka-group/mallocMC#172
IMO the most important question is, "Should we stop relaying on the nice template rules to be able to use clang format?"
Our current style guide: https://github.com/ComputationalRadiationPhysics/contributing/blob/master/codingGuideLines/cpp.md
The goal should be that we come soon to a automated formation because we have more and more distributed developer and a hand full projects with different styles.
@sbastrakov @ax3l @jkelling @SimeonEhrig @bernhardmgruber @BenjaminW3 @bertwesarg @j-stephan @ComputationalRadiationPhysics/alpaka-developers @ComputationalRadiationPhysics/picongpu-developers
Please answer the question: Do we should get rid of all formatting rules we can not apply with clang-format to provide a style file for all our projects.
Do we should get rid of all formatting rules we can not apply with clang-format to provide a style file for all our projects.
IMO yes we should.
Reasons are:
- it is not possible to maintain all projects with different style
- new developer will have it easier to contribute
Yes. I already proposed one for alpaka.
I think that would make a lot of sense.
Yes.
Yes, we should use an automated formatting tool and clang-format seems to be the dominant choice here.
As for the guidelines that cannot be enforced using clang-format: you can still keep them and apply them once clang-format supports the corresponding options. In the interim, we could mark the rules as "currently not enforceable but we wish we could have it".
By default my Emacs runs clang-format after each save, so: Yes
We have to keep in mind that we do not only agree on a specific set of clang-format rules but also on the specific clang-format version because each version produces slightly different results and newer versions support more features.
I would vote for clang-format 10 😉
I also think we should be using clang-format.
I agree!
As a sidenote: the template formatting proposed by the style guide seemed fairly easy to implement in clang-format. Here is a diff: llvm/llvm-project@master...bernhardmgruber:format
As a sidenote: the template formatting proposed by the style guide seemed fairly easy to implement in clang-format. Here is a diff: llvm/llvm-project@master...bernhardmgruber:format
If you can add an option in clang format for that and push a PR to clang/llvm it would be wonderful. Until it goes mainline we can aggree on e.g. clang-format 10.
Sounds nice, go for it :)
Please feel free to push onto #32 or cherry-pick from it as needed.
Carrying over the discussion from #19 to here.
clang-format appears to be relatively easy, I don't think we need to patch the LLVM source code for that.
However we will also require clang-tidy because clang-format doesn't handle stuff like camelCase or snake_case. I did a first test run on the alpaka codebase yesterday which immediately uncovered some bugs in clang-tidy. (Example: Constant parameters to functions/methods are not correctly detected and thus not fixed if they have the wrong casing.)
While working on the clang-tidy file I also noticed a huge load of additional options that (to me) appear immensely useful but are not really style-related. I suggest the following procedure:
- I will open a PR for the clang-format file along with a plain text file which includes the reasoning for the individual options.
- In parallel I will open a few bug reports on the clang-tidy tracker unless we want to cover the related issues by hand.
- I will open separate PRs for each of the clang-tidy options: casing, best practices, code modernization, ... along with text files that explain the reasoning.
Of course all PRs will be up for debate.
In the end we should have a nice style / best practices guide along with the means to actually enforce the rules. And it appears that CMake actually has builtin support for (at least) clang-tidy, so that is nice, too.
Nice plan of action @j-stephan !