lars.knoll at qt.io
Tue Jul 3 13:42:09 CEST 2018
On 3 Jul 2018, at 12:13, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io<mailto:Tor.arne.Vestbo at qt.io>> wrote:
On 3 Jul 2018, at 10:26, Lars Knoll <lars.knoll at qt.io<mailto:lars.knoll at qt.io>> wrote:
On 2 Jul 2018, at 16:52, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io<mailto:Tor.arne.Vestbo at qt.io>> wrote:
On 2 Jul 2018, at 16:49, Lars Knoll <lars.knoll at qt.io<mailto:lars.knoll at qt.io>> wrote:
On 2 Jul 2018, at 13:35, Tor Arne Vestbø <Tor.arne.Vestbo at qt.io<mailto:Tor.arne.Vestbo at qt.io>> wrote:
On 2 Jul 2018, at 12:56, Svenn-Arne Dragly <svenn-arne.dragly at qt.io<mailto:svenn-arne.dragly at qt.io>> wrote:
There are also many nice options set in the clang-format config found in Qt Creator's sources 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, I’m surprised clang-format doesn’t allow it to leave code untouched.
If that’s the case then I’m 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 isn’t per the format-file, but allowing us to ignore it if we feel the tailored code-formatting is better? Doesn’t this mean the bot will complain a lot?
The idea is to only run it on lines that the change touches anyway. That is apparently possible, so you will not get a full reformat of the file(s) you touched.
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.
It does formalise the rules, something I think is a good thing. To some extent it might introduce new ones, but the idea was to aim for a format file that is very close to our existing rules.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development