On Fri, Jun 10, 2016 at 2:53 PM, Hartmut Kaiser <[email protected]> wrote:
> 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. > Right, good catches. Another thing I missed was to add AfterControlStatement: true for BraceWrapping. > > This > > Standard: Cpp11 > > will (amongst other things) remove the whitespace between '> >' in > templates. Do we want that? > > I think yes. The days of needing '> >' should be over, and IIRC, we already use it in some parts. > > 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). > > That's probably the toughest question to answer. I think it would only make sense if we do the formatting in one big swoop, everything else will lead to too much noise. Tools like git bisect will still work, you just have this one commit inside which is either working or not. git blame won't work that easily anymore, so if we decide to have this, we should take the opportunity to make a "clear cut", maybe even removing some of the big files in out git history. As to how to apply and how to enforce the formatting, I am not sure what works best. We can certainly have a inspect like tool that checks and enforces the formatting. But yes, it will require everyone to use/install the tool, which might be a burden. Github doesn't allow us to install post commit hooks which automatically format the patches once you push them. pre commit hooks have the same problem as the editor, they only run on the developers machine. We could certainly have a bot though that goes through a pull request, applies clang-format, and then issues a PR to the original PR that includes the clang-format changes... resulting in a very convoluted setup ;) However, such a technique might be quite cool as we could also leverage clang-check, which is able to automatically rewrite code based on some other static analysis results ... > 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? > I have no idea how other projects handle this. However, I think the benefits outweigh the potential problems (turning off developers how find it too cumbersome etc.). It sometimes is really annoying to go through a PR which has flyby formatting changes. Those are really getting in the way. > > 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 >
_______________________________________________ hpx-users mailing list [email protected] https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
