Hi Hakan,
That's a great suggestion! We can definitely check in the file.
My only concern is that the file is imperfect right now - e.g.
"DataType* functionName()" is changed to "DataType *functionName()". I
am trying to force clang-format to pick the first behavior instead of
second. There may be other issues which will be uncovered if we try out
the plugin and tweak the parameters.
I should also mention the intent is to have an easy solution for
addressing style related concerns. This plugin should not trigger
wholesale changes in the codebase.
On 08/16/2016 06:57 PM, Hakan Memisoglu wrote:
Hi Harshad,
Since some plugins (e.g clang-format in emacs) that uses clang-format
traverses the file's parent folders to locate a .clang_format file.
Therefore, we can commit .clang_format file to the root folder, so
everyone can use.
On 08/16/2016 03:53 PM, Harshad Deshmukh wrote:
Hello,
I was playing with the clang-format tool today with the aim of coming
up with a uniform style specifications for the C++ source files.
Our style guide is largely based on Google's style guide, but we
deviate in some places (e.g. pointer alignment). I have created the
following .clang-format file which I believe closely represents our
style specifications.
I would be glad if you can try the file and let me know your
thoughts. Here are the steps:
1. Copy the .clang-format file to the Quickstep source root.
2. Run the clang-format plugin as folllows:
clang-format -style=file abc.hpp | tee abc-clang.hpp
Here's the explanation:
style=file -> This will force clang to pick up the .clang-format file
placed in Quickstep root and use it as the style reference.
abc.hpp -> A sample source file in the project. e.g.
query_execution/Worker.hpp
tee abc-clang.hpp -> The output from the clang-format tool, which
performs changes on abc.hpp and we temporarily save it as abc-clang.hpp
3. vimdiff abc.hpp abc-clang.hpp to see the differences. You can use
any other diff tool instead of vimdiff (e.g. meld)
The long term goal should be to perfect the clang-format file so that
it always gives trusted output. Then the pull request reviewer's
burden (wrt style related comments) is taken off. We could even
automate the style checking as a part of the CI.
--
Thanks,
Harshad
--
Thanks,
Harshad
