Thanks Thomas,
> I tried to set up a .clang-format file which mostly matches our current
> coding style (a few exceptions). I used clang-format from 3.8.
> The file can be seen here:
> https://gist.github.com/sithhell/5a0caa8b05a78c859390c2b7be174315
> Is this something we can work with?
>
> There is multitude of possibilities on how to integrate it in your
> workflow. The first would be to integrate it into your IDE/editor as
> described here:
> http://clang.llvm.org/docs/ClangFormat.html (look through the page, the
> editor setup comes at the end).
> There is also a description on how to format the changes you made before
> committing. I also found this little thingy here:
> https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-
> format
>
> Would be great if we could start using that tool to finally get rid of
> noisy reformatting changes in our commits.
The tool does a good job in reformatting things to a uniform style, which is
good and something we need. It naturally can't 100% match anybody's
preferred style, so everybody has to agree to some compromise.
Several comments:
a) I'd suggest not to introduce all of those alignment changes as this is
clearly something we have never done before. I would like to change the
following:
AlignConsecutiveAssignments: false # (was true)
AlignConsecutiveDeclarations: false # (was true)
AlignOperands: false # (was true)
These don't add to readability and usually turn into a nightmare for people
not using this tool.
This does not conform to the docs:
AlwaysBreakAfterDefinitionReturnType: false # (should be 'None')
The docs say not to use ExperimentalAutoDetectBinPacking in configuration
files as it might go away. Do we need it?
This should be changed
KeepEmptyLinesAtTheStartOfBlocks: false # (was true)
I don't think we have ever had empty lines at any start of a block.
I'm not sure about
ReflowComments: true
As this might clobber our doxygen comments. This requires more testing.
This
Standard: Cpp11
will (amongst other things) remove the whitespace between '> >' in
templates. Do we want that?
b) This is related to what code to apply the tool to.
As Thomas said, we can let it format only the code changed by a particular
commit. This has the advantage of minimal formatting related changes, but
has the disadvantage of source files now being hugely inconsistent.
Alternatively we could reformat all of the code base in one big sweep. This
would have the advantage of making everything consistent. The disadvantage
is that it destroys all of the edit-history.
Frankly, none of those options are really acceptable to me. And I have to
admit that I'm at a loss on how to proceed and I'm not even sure if there is
a way out. I'm open to suggestions.
c) Whatever we decide on what to format, relying on everybody to use the
tool before committing is unrealistic. Not every IDE/editor will have a
means of enforcing its usage. Thus, we would need a means of enforcing the
style. This could be done by checking the style on every commit (like
inspect) and loudly complaining about wrong formatting (which would clearly
put people off). Alternatively we could add a global git-pre-commit-hook and
perform the formatting automatically (not sure if this is feasible or
advisable, though).
So the bottom line is, for me currently this adds more questions than it
solves. More discussions are needed. Does anybody have any experience with
code style/formatting tools from other projects?
Thanks!
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
>
> Cheers,
> Thomas
>
> On 04/13/2016 11:48 AM, Hartmut Kaiser wrote:
> > John,
> >
> >> I am working on multiple projects, each has different formatting styles
> >> (annoying), but I recently discovered that one project uses a .clang-
> >> format file in the root folder to control the style and there is an
> >> eclipse plugin that searches the project path for the next-up .clang-
> >> format file and uses that to reformat the code you want changed (there
> are
> >> also Xcode/vim/other? ones too!).
> >>
> >> If there was a .clang-format file for hpx at the root folder of hpx,
> then
> >> my dream of having each project I work on, formatted according to the
> >> style of that project could be achieved.
> >>
> >> Does anyone have such a file for hpx, or can one convert easily one of
> >> their existing style format control thingies, to the clang-format
> format?
> >> (I'm sure it's quite trivial, I just don't want to do it myself).
> >
> > Having this would be cool indeed. I'm not aware of anybody using
> > clang-format for HPX, however.
> >
> > Regards Hartmut
> > ---------------
> > http://boost-spirit.com
> > http://stellar.cct.lsu.edu
> >
> >
> >
> > _______________________________________________
> > hpx-users mailing list
> > [email protected]
> > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> >
>
>
> --
> Thomas Heller
> Friedrich-Alexander-Universität Erlangen-Nürnberg
> Department Informatik - Lehrstuhl Rechnerarchitektur
> Martensstr. 3
> 91058 Erlangen
> Tel.: 09131/85-27018
> Fax: 09131/85-27912
> Email: [email protected]
> _______________________________________________
> hpx-users mailing list
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
