-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create a clang-format config that describes PCL Style Guide #2106
Comments
Also This is only useful if you don't have files that use completely different conventions. Then it leads to awful mixing of styles, but even then might be useful for manual use. |
Thanks for the hint, this looks extremely useful. With this we can get very close to my dream world, and reformatting of all existing code is not needed. @SergioRAgostinho So what about making a format specification which matches the style guide as close as possible, then replacing the style guide with this spec, and formatting all new code with it on Travis? |
Ok makes sense. Ultimately we want the configuration file to conform to the style guide and if earlier versions don't have enough features to do it exactly as desired, it's also not useful.
I would defer the decision till results of the first task are available for comparison. If we change the style spec we would need to deprecate the ones which are already in place. |
This is great!!! Enforcing clang-format will be a huge huge improvement! |
I'm working on it. |
The clang-format config enforces spacing and line-break guidelines from the PCL style guide, but not guidelines such as all cap constants or parenthesised return values etc. Unfortunately, clang-format has limitations that mean a couple of the style guidelines cannot be enforced, specifically: 1) Members affected by access qualifiers cannot be indented by one more level 2) Return type of functions will go on own separate line, not even the same line as template parameters as in one example from section 2.3 of the style guide resolves PointCloudLibrary#2106
Maybe makes sense to use clang-5, it has a number of new settings.
I don't think it matters what is shipped with a certain distro. This is auxiliary tooling only for devs and they can make this extra step of adding a PPA and installing 5.0 alongside with their standard clang.
Plus, in my dream world we have all the code base reformatted and a special Travis task that runs each pull request through formatter and fails if code does not match, outputting a diff that a contributor can apply to his code without any need to install whatever version of clang we happen to be using on Travis.
The text was updated successfully, but these errors were encountered: