> Really?? That sounds like a key feature, Im surprised clang-format doesnt > allow it to leave code untouched.
As already mentionned, there is always the option to tag code sections: // clang-format off ... // clang-format on > I thought we were going to run it as a fancy style bot, complaining if > the code isnt per the format-file, but allowing us to ignore it if we > feel the tailored code-formatting is better? Doesnt this mean the bot > will complain a lot? If there is the need for some human intervention after a bot work, for code formatting purposes, this would defeat any productivity goal. Philippe On Tue, 3 Jul 2018 10:13:06 +0000 Tor Arne Vestbø <[email protected]> wrote: > > > > On 3 Jul 2018, at 10:26, Lars Knoll <[email protected]> wrote: > > > >> On 2 Jul 2018, at 16:52, Tor Arne Vestbø <[email protected]> wrote: > >> > >> > >> > >>> On 2 Jul 2018, at 16:49, Lars Knoll <[email protected]> wrote: > >>> > >>> > >>>> On 2 Jul 2018, at 13:35, Tor Arne Vestbø <[email protected]> wrote: > >>>> > >>>> > >>>>> On 2 Jul 2018, at 12:56, Svenn-Arne Dragly <[email protected]> > >>>>> wrote: > >>>>> > >>>>> There are also many nice options set in the clang-format config found > >>>>> in Qt Creator's sources[2] which I think are interesting. For instance, > >>>>> "BinPackParameters: false" and "BinPackArguments: false" makes sure you > >>>>> to either put all arguments on one line or give if arguments will have > >>>>> one line each. This might be in the controversial category, but it is > >>>>> nice to enable while developing. It makes clang-format reflow the code > >>>>> consistently just by moving a single argument to a new line and running > >>>>> clang-format afterwards. > >>>> > >>>> I oppose mandating this style, through clang-format or otherwise. > >>> > >>> Having a common style that we start following is worth something. And > >>> yes, everybody will always find some details he won't like. So we won't > >>> get anywhere if everybody wants it exactly his way. > >> > >> Why not ease into this with the non-controversial style-rules first? > > > > clang-format will produce one way how the output is formatted. It will > > reformat your sources a certain way with less definitions in the file as > > well. So it's most likely better to have more rules defined as it'll give > > something closer to our implicitly used coding style. > > Really?? That sounds like a key feature, Im surprised clang-format doesnt > allow it to leave code untouched. > > If thats the case then Im not convinced this exercise is worth the churn. I > thought we were going to run it as a fancy style bot, complaining if the code > isnt per the format-file, but allowing us to ignore it if we feel the > tailored code-formatting is better? Doesnt this mean the bot will complain a > lot? > > We already have a style guide. Introducing clang-format to the mix does two > things: > > 1. Formalizes the style guide (to a certain degree) > 2. Introduces new style rules > > The second point was new to me, I was under the impression we were only going > to use it as a convenient tool to improve #1. > > Tor Arne > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
