Pcl: Create a clang-format config that describes PCL Style Guide

Created on 30 Nov 2017 · 5Comments · Source: PointCloudLibrary/pcl

Maybe makes sense to use clang-5, it has a number of new settings.

Should we aim already for 5 even though xenial is shipping 3.8?

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.

good first issue help wanted

Source

taketwo

👍2 😄1

Most helpful comment

I'm working on it.

JamesGiller on 11 Jul 2018

👍2

All 5 comments

Also clang-format-diff.py might be interesting for you. I allows to start incrementally using clang-format with new commits. Can be setup as git hook.

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.

hrnr on 30 Nov 2017

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?

taketwo on 30 Nov 2017

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.

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.

So what about making a format specification which matches the style guide as close as possible, then replacing the style guide.

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.