Re: [Development] commas in ctor-init-lists

On sexta-feira, 3 de junho de 2016 15:59:34 BRT Christian Kandeler wrote: > This kind of thing is an abomination that should never ever be allowed, > regardless of other coding style considerations. You can hardly even > tell whether the code is syntactically correct in both cases, let alone >

Re: [Development] commas in ctor-init-lists

Hi, Op 03/06/2016 om 08:28 schreef Martin Smith: but it is very structurally clean and in some circumstances I prefer it due to that. The structure is a comma separated list. Historically, the comma has always been placed directly after the first of two list items. The comma tells the

Re: [Development] commas in ctor-init-lists

>but it is very structurally clean and in some circumstances I prefer it due to >that. The structure is a comma separated list. Historically, the comma has always been placed directly after the first of two list items. The comma tells the reader that another list item will follow. There is

Re: [Development] commas in ctor-init-lists

>You can do this, given: Nobody does that. We always write: * You bla, or you boo, or you foo, and in this case we would normally write: You bla, you boo, or you foo. Even better: You bla, boo, or foo. You are inventing problems that don't exist. From:

Re: [Development] commas in ctor-init-lists

>Please allow that, I do, of course. Andre didn't. He wrote... >> if (blah || boo || foo) { //no line breaking allowed ...with the comment. From: Edward Welbourne Sent: Friday, June 3, 2016 9:54:43 AM To: Martin Smith; André Somers;

Re: [Development] commas in ctor-init-lists

>I am fairly sure he did in fact mean Eddie, we should write with precision. That's kind of the point of this thread. Some are saying putting the comma on the next line is more precise; some are saying it isn't. But note that you didn't defend my argument the same way you are defending

Re: [Development] commas in ctor-init-lists

Op 03/06/2016 om 08:52 schreef Martin Smith: You can do this, given: Nobody does that. We always write: * You bla, or you boo, or you foo, and in this case we would normally write: You bla, you boo, or you foo. Even better: You bla, boo, or foo. You are inventing problems that don't exist.

Re: [Development] commas in ctor-init-lists

>So that means that our C++ code should look like this then? >if (blah || boo || foo) { //no line breaking allowed In that case, yes, because the entire expression is short. And the ctor example that was used originally would also be on one line. Why not? Does the Qt coding standard require

Re: [Development] commas in ctor-init-lists

I wrote: >> Please allow that, Martin: > I do, of course. Andre didn't. He wrote... >>> if (blah || boo || foo) { //no line breaking allowed > ...with the comment. I am fairly sure he did in fact mean if (somee.really(long.and.complicated, expression) || another.such(that, makes,

Re: [Development] commas in ctor-init-lists

>My earliest encounters with this style were well into the present >millennium and I am fairly sure they were motivated by the relative ease >of fitting with #if-ery near the end of an initializer list, as has been >illustrated by a few advocates of this style. Then why not just add a note to the

Re: [Development] commas in ctor-init-lists

I think it would be instructive to hear the reasoning of the first engineer to add a ctor-init-list on separate lines with leading commas. I have been in the software engineering business since BEFORE Al Gore invented the internet, yet I have never been temped to start a line with a comma. What

Re: [Development] commas in ctor-init-lists

> I think it would be instructive to hear the reasoning of the first > engineer to add a ctor-init-list on separate lines with leading > commas. I have been in the software engineering business since BEFORE > Al Gore invented the internet, yet I have never been temped to start a > line with a

Re: [Development] commas in ctor-init-lists

André >> So that means that our C++ code should look like this then? >> if (blah || boo || foo) { //no line breaking allowed Martin > In that case, yes, because the entire expression is short. And the > ctor example that was used originally would also be on one line. Why > not? Does the Qt

Re: [Development] commas in ctor-init-lists

Hi all, my personal opinion: e.g. I prefer a commas *before* the variable in ctor, because it simplifies editing of a code. e.g. {code} Foo::Foo() : a, b, c {code} when I need to remove the 'c' variable, I need to remove and the ',' after 'b' too. {code} Foo::Foo()

Re: [Development] commas in ctor-init-lists

>Why devious? Because every human being learns from an early age that when forming a list of words separated by commas, each comma is placed immediately after the word. Putting the comma at the start is a deviation from what every human being first learned. No human being on the planet was

Re: [Development] commas in ctor-init-lists

On 06/03/2016 01:01 PM, Martin Smith wrote: Because every human being learns from an early age that when forming a list of words separated by commas, each comma is placed immediately after the word. Putting the comma at the start is a deviation from what every human being first learned. No

Re: [Development] commas in ctor-init-lists

On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > if (somee.really(long.and.complicated, expression) || another.such(that, > makes, the.line.too.long) || and.then.some.more()) To be perfectly blunt: such expressions shouldn't be allowed. Period. Neither with nor without line breaks.

Re: [Development] commas in ctor-init-lists

> On Jun 3, 2016, at 10:07 AM, Martin Smith wrote: > > I think it would be instructive to hear the reasoning of the first engineer > to add a ctor-init-list on separate lines with leading commas. I have been in > the software engineering business since BEFORE Al Gore

Re: [Development] commas in ctor-init-lists

Martin: >> Nobody does that. We always write: * You bla, or you boo, or you foo, >> and in this case we would normally write: You bla, you boo, or you >> foo. Even better: You bla, boo, or foo. You are inventing problems >> that don't exist. yet, when the list items are too big to inline and a

Re: [Development] Qt 5.7.0 rc packages for testing

Hi, just tested 5.7 RC on Ubuntu, looks good. (Also I see Qt Creator 4.01's project view has nicer icons.) But I spotted one problem, problem for me at least: When building a vanilla HelloQt widgets test app, I notice that the chrpath of the app just points to Qt's installation path, e.g.:

Re: [Development] commas in ctor-init-lists

On Friday 03 June 2016 14:26:03 André Somers wrote: > Op 03/06/2016 om 13:53 schreef Marc Mutz: > > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > >>if (somee.really(long.and.complicated, expression) || > >>another.such(that, > >> > >> makes, the.line.too.long) ||

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

On sexta-feira, 3 de junho de 2016 13:10:42 BRT Edward Welbourne wrote: > Thiago Macieira > > > Another thing to be very, VERY careful is about nested function call > > > > chains, as in: > >if (foo(bar(), baz(quux()), variable, xyz()) == variable) > > > > Can you tell me if bar, baz,

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

On Friday 03 June 2016 14:50:08 Edward Welbourne wrote: > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > >> if (somee.really(long.and.complicated, expression) || > >> another.such(that, makes, the.line.too.long) || and.then.some.more()) > > Marc Mutz responded: > > To be perfectly

Re: [Development] commas in ctor-init-lists

On sexta-feira, 3 de junho de 2016 08:42:20 BRT Eike Ziller wrote: > Why devious? > > Let’s have a look at the advantages of both styles: > > comma at the end: > > * feels more natural wrt natural languages > > comma at the start: > > * better visual alignment together with the : and , all at

Re: [Development] commas in ctor-init-lists

Op 03/06/2016 om 14:52 schreef Marc Mutz: On Friday 03 June 2016 14:26:03 André Somers wrote: Op 03/06/2016 om 13:53 schreef Marc Mutz: On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: if (somee.really(long.and.complicated, expression) || another.such(that, makes,

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

Thiago Macieira > Another thing to be very, VERY careful is about nested function call > chains, as in: > >if (foo(bar(), baz(quux()), variable, xyz()) == variable) > > Can you tell me if bar, baz, quux, or xyz modify variable? If so, what > is the call order? If any of bar, baz, quux or

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

Marc Mutz > The three clauses should stay three clauses if the action (their > then-block) is independent. If the then-block, as you seem to suggest, > is idenitical in tokens and semantics, then you *will* find a name to > describe it that doesn't just transliterate the original C++ code into >

Re: [Development] commas in ctor-init-lists

Op 03/06/2016 om 13:53 schreef Marc Mutz: On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) To be perfectly blunt: such expressions shouldn't be allowed.

[Development] when to Extract Method (was Re: commas in ctor-init-lists)

On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: >> if (somee.really(long.and.complicated, expression) || another.such(that, >> makes, the.line.too.long) || and.then.some.more()) Marc Mutz responded: > To be perfectly blunt: such expressions shouldn't be > allowed. Period. Neither with

Re: [Development] commas in ctor-init-lists

On sexta-feira, 3 de junho de 2016 13:05:10 BRT Ulf Hermann wrote: > On 06/03/2016 01:01 PM, Martin Smith wrote: > > Because every human being learns from an early age that when forming a > > list of words separated by commas, each comma is placed immediately after > > the word. Putting the comma

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

On sexta-feira, 3 de junho de 2016 12:50:08 BRT Edward Welbourne wrote: > > To be perfectly blunt: such expressions shouldn't be > > allowed. Period. Neither with nor without line breaks. Such monsters > > should be subjected to Extract Method with extreme prejudice. > > I'm fascinated - and

Re: [Development] commas in ctor-init-lists

Marc Mutz > We have the same problem in .pro files: QtC just appends new files, > always creating a patch the churns the old-last line in SOURCES. If it > would sort them in lexicographically, most additions would be > one-liners. Right - the "always add at end => always get conflict on merge"

Re: [Development] commas in ctor-init-lists

On sexta-feira, 3 de junho de 2016 12:58:01 BRT Edward Welbourne wrote: > Right - the "always add at end => always get conflict on merge" You get conflict on merge if it was within three lines of the other change, regardless of where the commas were. -- Thiago Macieira - thiago.macieira (AT)

[Development] [Announce] Qt 5.7.0 RC released

Hi all, Qt 5.7.0 RC is now released, see http://blog.qt.io/blog/2016/06/03/qt-5-7-0-release-candidate-available/ Big thanks to everyone involved! br, Jani Jani Heikkinen Release Manager The Qt Company

Re: [Development] commas in ctor-init-lists

Op 02/06/2016 om 21:47 schreef André Pönitz: On Wed, Jun 01, 2016 at 03:36:43PM +0200, Olivier Goffart wrote: On Mittwoch, 1. Juni 2016 12:56:12 CEST Simon Hausmann wrote: Hi, I'm in favorof changing our coding style to adopt the model you call "butt ugly" because I find it more appealing

Re: [Development] commas in ctor-init-lists

On Friday 03 June 2016 15:02:23 André Somers wrote: > > Then we don't need to talk about how to format multi-line ifs at all, > > because they do not exist anymore. > > Eh... So you move the same to a different method. How does that help? > You'd basically get the same expression but then in a

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

Or you could turn the second expression into a lamba for lazy evaluation and use it like bool computationNeeded = [](){ return another.such(that, makes, the.line.too.long) || and.then.some.more(); } if (alreadyComputed || computationNeeded()) On Fri, Jun 3, 2016 at 4:37 PM, Olivier Goffart

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

Which actually raises the question, can we get Extract Lambda refactoring ?:) On Fri, Jun 3, 2016 at 4:59 PM, NIkolai Marchenko wrote: > Or you could turn the second expression into a lamba for lazy evaluation > and use it like > bool computationNeeded = [](){ return

Re: [Development] commas in ctor-init-lists

On 06/03/2016 02:52 PM, Thiago Macieira wrote: I've seen a lot of code do: #ifdef FOO if (foo) { // something } else #endif if (bar) { // something else } else { // default } This kind of thing is an

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

On Freitag, 3. Juni 2016 12:50:08 CEST Edward Welbourne wrote: > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > >> if (somee.really(long.and.complicated, expression) || > >> another.such(that, makes, the.line.too.long) || and.then.some.more()) > Marc Mutz responded: > > To be

Re: [Development] when to Extract Method (was Re: commas in ctor-init-lists)

On Friday 03 June 2016 15:14:13 Edward Welbourne wrote: > Marc Mutz > > > The three clauses should stay three clauses if the action (their > > then-block) is independent. If the then-block, as you seem to suggest, > > is idenitical in tokens and semantics, then you *will* find a name to > >