[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [omr-dev] our coding standard
|
On 8/23/2016 9:29 AM, Daniel Heidinga wrote:
Is the root problem that there is a lack of automation for the existing
standard? Has anyone tried to automate 80-90% of the existing standard
with clang-format?
I have (with some help here).
For reference, I've pushed the prototype .clang-format file to GitHub
[1], and this commit [2] was the result of me applying the style to the
existing OMR code base.
This formatting file requires clang-format-3.8 or above for the keys
- AlwaysBreakAfterReturnType = AllDefinitions
- SortIncludes = false
- ReflowComments = false
Now, I provide this only because it's evidence it approaches doable.
Personally, having gone through the exercise, I still lean heavily
towards adopting a preexisting style that's 1) Easier to deploy 2) more
widely used.
I definitely understand the desire for clarity and consistency. The tool
will give us consistency, which leaves clarity, and to me, most of the
built in styles of clang-format have their own advantages and
disadvantages.
There's a lovely gist on github [3] that takes the same file, and
compares it in the different built in styles, so people can compare them.
[1]: https://github.com/mgaudet/omr/blob/ClangFormatting/.clang-format
[2]: ee857f1bc064fe96bb2f729c84ad5a06d1c4fb40. The diff, due to its
size, only loads in github sometimes:
https://github.com/mgaudet/omr/commit/ee857f1bc
[3]: https://gist.github.com/andrewseidl/8066c18e97c40086c183
