Re: [Development] Resolving coding style contentions

2018-12-15 Thread Sérgio Martins
On Thu, Nov 22, 2018 at 9:30 AM Frederik Gladhorn wrote: > (...) > So please give either tool a chance and let's see if we can reach consensus. I've tested uncrustify on clazy's code base and I was able to make a configuration file that adapts 100% to my preferred style, instead of me changing th

Re: [Development] Resolving coding style contentions

2018-11-20 Thread Lars Knoll
> On 19 Nov 2018, at 21:59, Ville Voutilainen > wrote: > > On Mon, 19 Nov 2018 at 22:41, Thiago Macieira > wrote: >> >> On Monday, 19 November 2018 12:03:06 PST Ville Voutilainen wrote: >>> I personally tend to split such things after an opening parenthesis. >>> Getting back to allowing ctor-

Re: [Development] Resolving coding style contentions

2018-11-19 Thread Ville Voutilainen
On Mon, 19 Nov 2018 at 22:41, Thiago Macieira wrote: > > On Monday, 19 November 2018 12:03:06 PST Ville Voutilainen wrote: > > I personally tend to split such things after an opening parenthesis. > > Getting back to allowing ctor-initializers to be written > > with a comma starting a line, I think

Re: [Development] Resolving coding style contentions

2018-11-19 Thread Thiago Macieira
On Monday, 19 November 2018 12:41:46 PST Thiago Macieira wrote: > It is allowed, unless the maintainer objects to it. > > I object to it in QtCore. I also insist that the opening brace in non-nested classes, enums and in any functions be placed in a new line (unless the entire function is in one

Re: [Development] Resolving coding style contentions

2018-11-19 Thread Thiago Macieira
On Monday, 19 November 2018 12:03:06 PST Ville Voutilainen wrote: > I personally tend to split such things after an opening parenthesis. > Getting back to allowing ctor-initializers to be written > with a comma starting a line, I think we should just allow it; the > benefit of not having noise in a

Re: [Development] Resolving coding style contentions

2018-11-19 Thread Ville Voutilainen
On Mon, 19 Nov 2018 at 18:37, Thiago Macieira wrote: > > On Monday, 19 November 2018 02:34:09 PST Edward Welbourne wrote: > > I note a glaring exception to that: after the opening parenthesis of > > a parameter list, if the line would otherwise be too long: > > > > auto variable = > > QCharacter

Re: [Development] Resolving coding style contentions

2018-11-19 Thread Thiago Macieira
On Monday, 19 November 2018 02:34:09 PST Edward Welbourne wrote: > I note a glaring exception to that: after the opening parenthesis of > a parameter list, if the line would otherwise be too long: > > auto variable = > QCharacteristicallyVerboseClassName::characteristicallyLongFunctionName( > fi

Re: [Development] Resolving coding style contentions

2018-11-19 Thread Edward Welbourne
On Sunday, 18 November 2018 05:30:26 PST Sze Howe Koh wrote: >> I'd just like to know: Did the Qt Project ever reach a decision? If not, >> how can we reach one? (Linked to the discussion of constructor initializers like MyClass(type param) : MyBase(param) , myMember(param) using comma

Re: [Development] Resolving coding style contentions

2018-11-18 Thread Thiago Macieira
On Sunday, 18 November 2018 05:30:26 PST Sze Howe Koh wrote: > I'd just like to know: Did the Qt Project ever reach a decision? If not, > how can we reach one? I don't think we did. Right now, it's up to the maintainer's discretion. QtCore opts into the rule: newlines are whitespace. Corollary:

[Development] Resolving coding style contentions

2018-11-18 Thread Sze Howe Koh
Hi all, I can't find a final decision on this topic: http://lists.qt-project.org/pipermail/development/2016-June/026058.html The arguments from both sides were numerous (browse through http://lists.qt-project.org/pipermail/development/2016-June/thread.html ). I would like to avoid a re-hash of th