Maintaining coding style is hard without good tool support. EditorConfig seems to be the best way to accomplish that over a wide variety of platforms. Are there any volunteers to try to implement ITK’s style guide in an .editorconfig file? It is totally OK if this is done incrementally - somebody does a first pass implementing a few rules, which gets expaned by someone else etc.
A possible starting point would be translating ITK’s uncrustify configuration files. uncrustify_itk.cfg is meant to not overly modify the user-written code, even if it means not fully enforcing the ITK style. uncrustify_itk_aggressive.cfg tries to enforce as many rules as possible, with a side-effect of creating more un-compilable modifications.
Also, as we are doing a major overhaul of the library right now, it might be worthwhile considering a change in code style. We could relax the rules somewhat, or turn some rules into recommendations (e.g. space around template parameters FilterType<ImageType> vs FilterType< ImageType >). We could also completely rework the rules to make them easier to be automatically and reliably enforced (by e.g. clang-format). A more standard style (such as Allman) would be easier to enforce than a completely custom style (currently effective ITK style).
I just found out that EditorConfig does not have many options. I created a patch to add it. Visual Studio has to be restarted (closing and opening the project is not enough) for “format selection (Ctrl-K, Ctrl-F)” and “format document (Ctrl-K, Ctrl-D)” commands to start behaving differently.
Whatever style or set of rules we agree on would be fine as long as we stick to it. Automating the enforcement of the style would help. The ITK Software Guide (Appendix 3) already covers it extensively. If there is a tool that is able to enforce, show warnings for all aspects, much like PEP8/Flake8 for Python, then we should find it. If there is no such a tool, we’ll need to take care ourselves to stick to the set of rules as best we can, whether they are in one form or another (whether we adopt FilterType<ImageType> against the current FilterType< ImageType >).
EditorConfig seems a reasonable choice. I don’t know of any other.
Some other thoughts:
Automatically adopting the proposed .editorconfig for ITK for the configured IDE would be required.
I ignore whether/which IDE’s are able to use different .editorconfig for different projects. If a tool/way to allow this for those developing projects with different style conventions could be found, the adoption of ITK’s potential .editorconfig could be greater.
My vote would be for Clang-format which is available on the major platforms and integrates perfectly with git via git-clang-format. All you need is a .clangformat at the top level of the project. Visual Studio, Visual Studio Code, Qt Creator, Emacs and Vi all can support clang-format in one fashion or another. This also seems to be the way whole host of other projects are heading.