subject:"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 
> semantics.
> Factor out ifdefs into dedicated functions whenever possible. You'll be 
> glad you did, and even more so the people who have to read your code later.

Agreed. Like I said, #ifdefs are an eye-sore of their own and should be 
avoided as much as possible. Therefore, I don't consider them valid arguments 
for placing commas at the beginning of a line.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-03 Thread Christian Kandeler


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 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 
semantics.
Factor out ifdefs into dedicated functions whenever possible. You'll be 
glad you did, and even more so the people who have to read your code later.



Christian
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-03 Thread Marc Mutz

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 method of it's own?

You have more freedom to format the code in the method. You can use a multi-
line return statement, already an improvement over a multi-line if statement, 
or you can use guard clauses, possibly interspersed with comments...

But the main advantage is that you replaced an ugly, unreadable construction 
with a *name*. We humans like to name things. E.g. I don't like unnamed 
lambdas. I think it's much preferable to assign a lambda to an auto variable 
than to inline it into the expression, precisely because it drives people 
crazy when they need to come up with a name (hi, Anton :). But that mental 
effort expended by that one person (and their reviewers, hi Eddy) is saved for 
everyone else (iff the name chosen is descriptive).

As Fowler argues in Refactoring, sometimes the Smell is so bad that you 
Extract Method even if the result is longer _at the call site_ than the 
original code was.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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, 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. Such monsters should be subjected
to Extract Method with extreme prejudice.

Thanks,
Marc

Fine. Lets replace it with something like this then:

if (theValue ==
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 ||
theValue ==
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 ||
theValue ==
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) {

}

Umm... same thing?

What I'm saying is:

- Multi-line conditions in if statements should *always* be refactored to a
   single function call.

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 method of it's own?



[...]

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.

I requested this quite a while ago already.

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 the start

Alignment of the *comma* is not important. It's a small thing, just a few 
pixels tall. It's only there because we need to have it.

What's important is the aligment of the variable names. Regardless of where 
you put the comma, the variable names will align. Therefore, I don't think the 
above is an argument.

> * easier diff when adding something at the end (which is commonly done)

True, though with intra-line and across-line diffs that Gerrit shows, this is 
minimised. It shows that the previous line was unmodified except for the comma.

> * easier rearrangement when it involves the last item

True, but same as above.

> * easier ifdef’ing of individual items

Only if it involves the last item. And since #ifdef is a sore eye anyway, 
using a sore-eye construction for the last item is not going to make it much 
worse.

Please also note that this only applies to ctors with already-split lines. 
They often don't start like that. They often have a few variables and are 
initialised like:

Foo::Foo()
: i(0), status(None), enabled(false)
{
// ...
}

When that grows, it becomes:

Foo::Foo()
: QObject(*new FooPrivate), ptr(nullptr), i(0), 
  status(None), enabled(false)
{
// ...
}

Besides, do we need a rule so that our if-else chains with #ifdef in the 
middle be nice too? I've seen a lot of code do:

#ifdef FOO
if (foo) {
// something
} else
#endif
if (bar) {
// something else
} else {
// default
}

That if-else chain violates our coding standard. Should we adapt it so that it 
works with #if in the middle? I would prefer not.

(there's trick you can do to minimise this; exercise left to the reader)

> The advantages of the one are the disadvantages of the other.
> 
> So some people argue that “feels more natural” overweighs the perceived
> small advantages of comma at the start.
> And some other people argue that
> coding has not much to do with natural languages anyhow, the “small”
> advantages are worth the change, and it doesn’t feel unnatural anymore
> after getting used to it. 

Then let's insert a space *before* *every* comma!

> > Then why not just add a note to the Qt coding style saying that using the
> > leading comma is allowed|recommended when using conditional compilation
> > in a comma list? Why does it have to be uniform throughout the entire
> > code base? Sometimes diffs are hard to read.
> 
> Possibly because for some people consistency is of higher value.

Agreed.

Consistency is important for me, which is why I reject patches to QtCore that 
contain leading commas.

I only allow it if it is necessary because of #if, which already made it a 
sore-eye in the first place. That is, in QtCore, it's only allowed when 
strictly required.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 at the start is a deviation from what every
> > human being first learned. No human being on the planet was taught to put
> > a comma at the beginning of a line.
> I think you are a western supremacist

Do you know of any language that even has a space before a comma?

I know French requires a space before any punctuation consisting of more than 
one drawing (! ? ; and :  all have two drawings), which means a comma is 
excluded from that and is placed right next to the previous word, without 
space.

In English, that is so much so that it comes *inside* the closing quote of a 
quotation, even if the quotation did not have a comma there.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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"
anti-pattern, whereas ordering things (members, files, fields, methods,
whatever) in some coherent way related to their meaning or just simply
dumbly alphabetically would mean additions typically happen all over the
list, so contemporary changes seldom collide and merges are easy.

But we digress,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-03 Thread 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, 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. Such monsters should be subjected
> > to Extract Method with extreme prejudice.
> > 
> > Thanks,
> > Marc
> 
> Fine. Lets replace it with something like this then:
> 
> if (theValue ==
> MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 ||
> theValue ==
> MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 ||
> theValue ==
> MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) {
> 
> }

Umm... same thing?

What I'm saying is:

- Multi-line conditions in if statements should *always* be refactored to a
  single function call.

Then we don't need to talk about how to format multi-line ifs at all, because 
they do not exist anymore.

Same goes for other expressions, too, really, but a free statement is much 
easier line-wrapped than an if, whose then-clause' opening brace is lost in 
complete noise with a multi-line if statement.

I was also saying earlier, but it probably was overlooked:

- Conditional compilation members should be initied by nsdmi (or placed in a
  struct with a default ctor that inits the values, so the member of struct
  type can be omitted from the ctor-init-list).

And we can leave trailing comma ctor-init-lists in, because there will be no 
more conditional compilation in ctor-init-lists. And with a minimum of 
foresight, a class author will place a field last than can stay last, to 
accomodate new fields. Even the subset of C++11 features that we can use will 
make much of the argumentation for leading commas moot. Even more so if we 
find (qcd.h doesn't track it) that we can also use trailing comma in enums.

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.

Here's an example (QLabel) which was problematic in the past because of the 
many preprocessor conditionals (attached). NSDMI doesn't work for bit-fields, 
but if I were to finish that patch, the bit fields would probably be replaced 
by a uint flags field.

Thanks,
Marc


-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
From 62027ef0559c235adc0d49fb49a75c47a5cc8f92 Mon Sep 17 00:00:00 2001
From: Marc Mutz 
Date: Fri, 3 Jun 2016 14:46:07 +0200
Subject: [PATCH] QLabelPrivate: use nsdmi

Change-Id: Ib094a2c01bb4009c780423b810546681591c2a96
---
 src/widgets/widgets/qlabel.cpp |   26 --
 src/widgets/widgets/qlabel_p.h |   22 +++---
 2 files changed, 11 insertions(+), 37 deletions(-)

diff --git a/src/widgets/widgets/qlabel.cpp b/src/widgets/widgets/qlabel.cpp
index 5db1013..c12710b 100644
--- a/src/widgets/widgets/qlabel.cpp
+++ b/src/widgets/widgets/qlabel.cpp
@@ -61,33 +61,7 @@ QT_BEGIN_NAMESPACE
 
 QLabelPrivate::QLabelPrivate()
 : QFramePrivate(),
-  sh(),
-  msh(),
-  text(),
-  pixmap(Q_NULLPTR),
-  scaledpixmap(Q_NULLPTR),
-  cachedimage(Q_NULLPTR),
-#ifndef QT_NO_PICTURE
-  picture(Q_NULLPTR),
-#endif
-#ifndef QT_NO_MOVIE
-  movie(),
-#endif
-  control(Q_NULLPTR),
-  shortcutCursor(),
-#ifndef QT_NO_CURSOR
-  cursor(),
-#endif
-#ifndef QT_NO_SHORTCUT
-  buddy(),
-  shortcutId(0),
-#endif
-  textformat(Qt::AutoText),
-  textInteractionFlags(Qt::LinksAccessibleByMouse),
   sizePolicy(),
-  margin(0),
-  align(Qt::AlignLeft | Qt::AlignVCenter | Qt::TextExpandTabs),
-  indent(-1),
   valid_hints(false),
   scaledcontents(false),
   textLayoutDirty(false),
diff --git a/src/widgets/widgets/qlabel_p.h b/src/widgets/widgets/qlabel_p.h
index dce9ba7..9c687e27 100644
--- a/src/widgets/widgets/qlabel_p.h
+++ b/src/widgets/widgets/qlabel_p.h
@@ -109,30 +109,30 @@ public:
 mutable QSize sh;
 mutable QSize msh;
 QString text;
-QPixmap  *pixmap;
-QPixmap *scaledpixmap;
-QImage *cachedimage;
+QPixmap *pixmap = nullptr;
+QPixmap *scaledpixmap = nullptr;
+QImage *cachedimage = nullptr;
 #ifndef QT_NO_PICTURE
-QPicture *picture;
+QPicture *picture = nullptr;
 #endif
 #ifndef QT_NO_MOVIE
 QPointer movie;
 #endif
-mutable QWidgetTextControl *control;
+mutable QWidgetTextControl *control = nullptr;
 mutable QTextCursor shortcutCursor;
 #ifndef QT_NO_CURSOR
 QCursor cursor;
 #endif
 #ifndef QT_NO_SHORTCUT
 QPointer buddy;
-int shortcutId;
+int shortcutId = 0;
 #endif
-

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. Period. Neither
with nor without line breaks. Such monsters should be subjected to Extract
Method with extreme prejudice.

Thanks,
Marc


Fine. Lets replace it with something like this then:

if (theValue == 
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 || 
theValue == 
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 || 
theValue == 
MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) {


}

André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-03 Thread 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. Period. Neither 
with nor without line breaks. Such monsters should be subjected to Extract 
Method with extreme prejudice.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-03 Thread Ulf Hermann


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 human being on the planet was taught to put a comma at the 
beginning of a line.


I think you are a western supremacist ;)

Now the debate is over.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 taught to put a comma at the 
beginning of a line.

But this is not an issue of readability or feeling natural. The three formats 
are equally readable. One can even argue that if the list is long, the single 
line format is less readable than either of the multiple line formats.

Nor should the auto-indent feature of your favorite editor have any sway. My 
editor handles either multi-line format with ease. If yours can't, get better 
one.

So we really just have the conditional compilation issue and the diff noise 
issue. These are valid issues.

So, here is a simple Qt coding style guideline.

In a comma list, be consistent about where the comma is placed. Either place it 
immediately after each list item (comma-last), or at the start of each line 
(comma-first). When using conditional compilation in a comma-last list, change 
the entire list to be comma-first. Once a list becomes comma-first, never 
change it to comma-last, even when the conditional compilation is removed.

martin

From: Eike Ziller
Sent: Friday, June 3, 2016 10:42:20 AM
To: Martin Smith
Cc: Edward Welbourne; André Somers; development@qt-project.org
Subject: Re: [Development] commas in ctor-init-lists

> On Jun 3, 2016, at 10:07 AM, Martin Smith <martin.sm...@qt.io> 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 invented the internet, 
> yet I have never been temped to start a line with a comma.

> What devious thinking would cause one to do that in the first place?

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 the start
* easier diff when adding something at the end (which is commonly done)
* easier rearrangement when it involves the last item
* easier ifdef’ing of individual items

The advantages of the one are the disadvantages of the other.

So some people argue that “feels more natural” overweighs the perceived small 
advantages of comma at the start.
And some other people argue that coding has not much to do with natural 
languages anyhow, the “small” advantages are worth the change, and it doesn’t 
feel unnatural anymore after getting used to it.

> Then why not just add a note to the Qt coding style saying that using the 
> leading comma is allowed|recommended when using conditional compilation in a 
> comma list? Why does it have to be uniform throughout the entire code base? 
> Sometimes diffs are hard to read.

Possibly because for some people consistency is of higher value.

(Disclaimer: I personally really don’t care which style is taken.)

Br, Eike

> martin
>
> 
> From: Development <development-bounces+martin.smith=qt...@qt-project.org> on 
> behalf of Martin Smith <martin.sm...@qt.io>
> Sent: Friday, June 3, 2016 10:00:26 AM
> To: Edward Welbourne; André Somers; development@qt-project.org
> Subject: 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; development@qt-project.org
> Subject: 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 coding standard require each expression to be on a
>> separate line? I thought they should be on separate lines when the
>> list is too long to be on a single line.
>
> Please allow that, in giving illustrations, short texts may be used as
> surrogates for tacitly long ones, so that
>
>  if (blah
>  || boo
>  || foo) {
>  some.code();
>  }
>
> is tacitly standing for
>
>  if (somee.really(long.and.complicated, expression)
>  || another.such(that, makes, the.line.too.long)
>  || and.then.some.more()) {
>  some.code()

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

2016-06-03 Thread Eike Ziller


> On Jun 3, 2016, at 10:07 AM, Martin Smith <martin.sm...@qt.io> 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 invented the internet, 
> yet I have never been temped to start a line with a comma.

> What devious thinking would cause one to do that in the first place?

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 the start
* easier diff when adding something at the end (which is commonly done)
* easier rearrangement when it involves the last item
* easier ifdef’ing of individual items

The advantages of the one are the disadvantages of the other.

So some people argue that “feels more natural” overweighs the perceived small 
advantages of comma at the start.
And some other people argue that coding has not much to do with natural 
languages anyhow, the “small” advantages are worth the change, and it doesn’t 
feel unnatural anymore after getting used to it.

> Then why not just add a note to the Qt coding style saying that using the 
> leading comma is allowed|recommended when using conditional compilation in a 
> comma list? Why does it have to be uniform throughout the entire code base? 
> Sometimes diffs are hard to read.

Possibly because for some people consistency is of higher value.

(Disclaimer: I personally really don’t care which style is taken.)

Br, Eike

> martin
> 
> 
> From: Development <development-bounces+martin.smith=qt...@qt-project.org> on 
> behalf of Martin Smith <martin.sm...@qt.io>
> Sent: Friday, June 3, 2016 10:00:26 AM
> To: Edward Welbourne; André Somers; development@qt-project.org
> Subject: 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; development@qt-project.org
> Subject: 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 coding standard require each expression to be on a
>> separate line? I thought they should be on separate lines when the
>> list is too long to be on a single line.
> 
> Please allow that, in giving illustrations, short texts may be used as
> surrogates for tacitly long ones, so that
> 
>  if (blah
>  || boo
>  || foo) {
>  some.code();
>  }
> 
> is tacitly standing for
> 
>  if (somee.really(long.and.complicated, expression)
>  || another.such(that, makes, the.line.too.long)
>  || and.then.some.more()) {
>  some.code();
>  }
> 
> in examples - it gets boring to write the examples out in full like that
> and I would hope everyone is capable of interpolating the big long ugly
> expressions for which short tokens are used in illustrations.
> 
>Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
+123 45 6789012
http://qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 Qt coding style saying that using the 
leading comma is allowed|recommended when using conditional compilation in a 
comma list? Why does it have to be uniform throughout the entire code base? 
Sometimes diffs are hard to read.

martin

From: Edward Welbourne
Sent: Friday, June 3, 2016 10:14:38 AM
To: Martin Smith; André Somers; development@qt-project.org
Subject: 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 devious thinking would cause one to do that in
> the first place?

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.  As a few others have
commented, I found it perverse at first but got used to it fairly
swiftly.  I strongly suspect the #if-ery argument is what first prompted
someone to want to do this, but I imagine the invention of this style is
lost in the mists of time.

Incidentally, the problem with this style at the start of an initializer
list can usually be overcome by including a base-class construction
explicitly, despite its being fatuous:

Derived::Derived(type arg)
  : Base() // fatuous and unnecessary, but accommodates:
#if FEEPING
  , creature(itis)
#endif
  , etc(arg)

Not that I wish to particularly advocate either side of the debate; I'd
just rather both sides' cases were properly and clearly stated ...

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 Andre's, yet his reply to me was explicitly absolute, where mine 
was not.

martin

From: Edward Welbourne
Sent: Friday, June 3, 2016 10:05:52 AM
To: Martin Smith; André Somers; development@qt-project.org
Subject: 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, the.line.too.long) || and.then.some.more())

and that he was, at that point, reading the earlier objection as meaning
we wouldn't be allowed to split this line.  I disagree - our coding
style does allow splitting it as

  if (somee.really(long.and.complicated, expression)
  || another.such(that, makes, the.line.too.long)
  || and.then.some.more())

unless I misunderstood a rule I didn't like - but I'm fairly sure he did
mean to use blah, boo and foo as metasyntactic variables.

Please take a little time to read other folks' contributions charitably,
rather than rushing to find fault with them.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-03 Thread Denis Shienkov


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()

: a

,  b

   ,  c

{code}

but here I need to remove only whole line ',c' .. :)


Besides, it is consistent with :

{code}

int sum = a

+ b

+ c;


bool result = a

|| b

|| c;

{code}


BR,

Denis

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 devious thinking would cause one to do that in
> the first place?

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.  As a few others have
commented, I found it perverse at first but got used to it fairly
swiftly.  I strongly suspect the #if-ery argument is what first prompted
someone to want to do this, but I imagine the invention of this style is
lost in the mists of time.

Incidentally, the problem with this style at the start of an initializer
list can usually be overcome by including a base-class construction
explicitly, despite its being fatuous:

Derived::Derived(type arg)
  : Base() // fatuous and unnecessary, but accommodates:
#if FEEPING
  , creature(itis)
#endif
  , etc(arg)

Not that I wish to particularly advocate either side of the debate; I'd
just rather both sides' cases were properly and clearly stated ...

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 devious thinking 
would cause one to do that in the first place?

martin


From: Development <development-bounces+martin.smith=qt...@qt-project.org> on 
behalf of Martin Smith <martin.sm...@qt.io>
Sent: Friday, June 3, 2016 10:00:26 AM
To: Edward Welbourne; André Somers; development@qt-project.org
Subject: 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; development@qt-project.org
Subject: 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 coding standard require each expression to be on a
> separate line? I thought they should be on separate lines when the
> list is too long to be on a single line.

Please allow that, in giving illustrations, short texts may be used as
surrogates for tacitly long ones, so that

  if (blah
  || boo
  || foo) {
  some.code();
  }

is tacitly standing for

  if (somee.really(long.and.complicated, expression)
  || another.such(that, makes, the.line.too.long)
  || and.then.some.more()) {
  some.code();
  }

in examples - it gets boring to write the examples out in full like that
and I would hope everyone is capable of interpolating the big long ugly
expressions for which short tokens are used in illustrations.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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, the.line.too.long) || and.then.some.more())

and that he was, at that point, reading the earlier objection as meaning
we wouldn't be allowed to split this line.  I disagree - our coding
style does allow splitting it as

  if (somee.really(long.and.complicated, expression)
  || another.such(that, makes, the.line.too.long)
  || and.then.some.more())

unless I misunderstood a rule I didn't like - but I'm fairly sure he did
mean to use blah, boo and foo as metasyntactic variables.

Please take a little time to read other folks' contributions charitably,
rather than rushing to find fault with them.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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; development@qt-project.org
Subject: 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 coding standard require each expression to be on a
> separate line? I thought they should be on separate lines when the
> list is too long to be on a single line.

Please allow that, in giving illustrations, short texts may be used as
surrogates for tacitly long ones, so that

  if (blah
  || boo
  || foo) {
  some.code();
  }

is tacitly standing for

  if (somee.really(long.and.complicated, expression)
  || another.such(that, makes, the.line.too.long)
  || and.then.some.more()) {
  some.code();
  }

in examples - it gets boring to write the examples out in full like that
and I would hope everyone is capable of interpolating the big long ugly
expressions for which short tokens are used in illustrations.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 coding standard require each expression to be on a
> separate line? I thought they should be on separate lines when the
> list is too long to be on a single line.

Please allow that, in giving illustrations, short texts may be used as
surrogates for tacitly long ones, so that

  if (blah
  || boo
  || foo) {
  some.code();
  }

is tacitly standing for

  if (somee.really(long.and.complicated, expression)
  || another.such(that, makes, the.line.too.long)
  || and.then.some.more()) {
  some.code();
  }

in examples - it gets boring to write the examples out in full like that
and I would hope everyone is capable of interpolating the big long ugly
expressions for which short tokens are used in illustrations.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 display list is
used, I would most certainly have
 * first thing,
 * subsequent ... things,
 * penultimate thing or
 * final thing.

with the or on the end of the penultimate entry.  Our coding style asks
for the equivalent of that "or" being on the start of the final thing.
I can even argue for why that makes a certain sense - it *is* easy to
miss that trailing "or" on the end of the penultimate item, which *can*
make it harder for the reader to tell whether this is an or-list or an
and-list.  Yet I do in fact use the style just illustrated and would
only use the other if I wanted to put particular emphasis on the "or".

However, as others have pointed out, arguing by analogy with typographic
practice in English is not really pertinent to the case in point.  This
is code; we put parentheses around things for quite different reasons
than English text does and we use commas differently, too.

André:
> So that means that our C++ code should look like this then?
>
> if (blah || boo || foo) {  //no line breaking allowed
> something();
> }

No.  Our coding style quite explicitly says that you can split lines as
long as the operator appears at the start of the line.  I personally
find that butt-ugly; but it's what our coding style mandates so I go
along with it.  Regularity makes for ease of reading, once you are
familiar with the form being followed, as long as it's not too
perversely bad - so I tolerate that every job I've ever had has obliged
me to use a coding style I don't like.  I can think of a case where that
style was so bad it got in the way, but what we presently have as our
coding style is half-way decent and that's good enough for me.  There is
too much diversity of preference for any coding style to be blessed in
the eyes of all, so we live with a consensus all can endure.

I do, however, like the suggestion that we formalise it all into a
scriptable style that can be what the code gets mashed into on commit,
with each developer free to mash into any style they like on checkout.
Show me an implementation of that and I'll be happy to see the end of
all flame-wars about code layout.

Other than that, changing coding style just leads to inconsistency in
the code-base; even a change to a style I prefer needs a stronger
argument for it than "I prefer it" to get over the cost of the
transitional phase with some code in the old style, some in the new.
I'd sooner stick to a style I don't like but can read well enough than
have the approved style keep changing.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 each expression to be on a separate line? I thought they 
should be on separate lines when the list is too long to be on a single line.

martin

From: André Somers <an...@familiesomers.nl>
Sent: Friday, June 3, 2016 9:25:18 AM
To: Martin Smith; development@qt-project.org
Subject: 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.
>
If you say so.

So that means that our C++ code should look like this then?

if (blah || boo || foo) {  //no line breaking allowed
something();
}

What a load of nonsense.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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.


If you say so.

So that means that our C++ code should look like this then?

if (blah || boo || foo) {  //no line breaking allowed
   something();
}

What a load of nonsense.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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: Development <development-bounces+martin.smith=qt...@qt-project.org> on 
behalf of André Somers <an...@familiesomers.nl>
Sent: Friday, June 3, 2016 8:45:29 AM
To: development@qt-project.org
Subject: 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 
> reader that another list item will follow. There is nothing to clean. Note 
> the comma I used appeared right after the word "Historically,"  as did that 
> one, and that one appeared right after the word "none."  The comma has never 
> appeared as the first character of anything.
>
>> Note there is a related coding style violation for if statements.
> The relationship is tenuous. '||' is an operator, ',' is a separator. '||' 
> represents a word to the reader ( "or"). The comma doesn't represent a word.
Well, if we go that way, lists of conditions are often written like this:
You can do this, given:
* You bla, or
* You boo, or
* You foo

Note the position of the or. Does that mean that the equivalent C++
should look like this:
if ( bla ||
   boo ||
   foo )
{ //we can debate the position of the opening brace here as well...
 do this...
}

No. I think this drawing of parallels with natural language formatting
is not very productive. Code is not natural language and we should not
apply the same formatting rules to them.


>
>> This has the same benefits for diffs as the leading comma,
> Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff 
> with an option to suppress it?
Ehhh? The diff is there and is significant, isn't it? So it should not
be suppressed unlike some stray white space differences.


Anyway, I am all for using an auto-formatter. I think they are good
enough nowadays. They may not in every circumstance generate the
absolute most beautiful layout, but it saves a huge amount of time not
having to care for it anymore, not getting style^Hformatting related
-1's from the CI any more and not having to debate it any more. So I
think it is well worth the loss of prefered formatting here and there.
And yes, you can use your own prefered format locally if you please, as
long as it gets reformatted to the standard one on submission. Sounds
ideal to me.


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 and I find that it makes diffs
easier to read.

Simon

+1  as well, if someone counts the votes!

Why would anyone bother to count votes before any (theoretically binding
or non-binding, doesn't seem to matter) result of voting gets ignored by
the next submitter anyway?

Well, if the rules would be encoded in a clang-format  format that is 
used in a commit hook, that would not be an issue any more, would it?


André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 reader that another list item will follow.
There is nothing to clean. Note the comma I used appeared right after the word
"Historically," as did that one, and that one appeared right after the word
"none." The comma has never appeared as the first character of anything.

Note there is a related coding style violation for if statements.

The relationship is tenuous. '||' is an operator, ',' is a separator. '||' represents a
word to the reader ( "or"). The comma doesn't represent a word.

Well, if we go that way, lists of conditions are often written like this:
You can do this, given:
* You bla, or
* You boo, or
* You foo

Note the position of the or. Does that mean that the equivalent C++
should look like this:

if ( bla ||
boo ||
foo )
{ //we can debate the position of the opening brace here as well...
do this...
}

No. I think this drawing of parallels with natural language formatting
is not very productive. Code is not natural language and we should not
apply the same formatting rules to them.

This has the same benefits for diffs as the leading comma,

Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff with
an option to suppress it?
Ehhh? The diff is there and is significant, isn't it? So it should not
be suppressed unlike some stray white space differences.

Anyway, I am all for using an auto-formatter. I think they are good
enough nowadays. They may not in every circumstance generate the
absolute most beautiful layout, but it saves a huge amount of time not
having to care for it anymore, not getting style^Hformatting related
-1's from the CI any more and not having to debate it any more. So I
think it is well worth the loss of prefered formatting here and there.
And yes, you can use your own prefered format locally if you please, as
long as it gets reformatted to the standard one on submission. Sounds
ideal to me.

André

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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 nothing to clean. Note the 
comma I used appeared right after the word "Historically,"  as did that one, 
and that one appeared right after the word "none."  The comma has never 
appeared as the first character of anything.

>Note there is a related coding style violation for if statements.

The relationship is tenuous. '||' is an operator, ',' is a separator. '||' 
represents a word to the reader ( "or"). The comma doesn't represent a word.

>This has the same benefits for diffs as the leading comma,

Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff with 
an option to suppress it?

From: Development <development-bounces+martin.smith=qt...@qt-project.org> on 
behalf of Allan Sandfeld Jensen <k...@carewolf.com>
Sent: Friday, June 3, 2016 2:02:55 AM
To: development@qt-project.org
Subject: Re: [Development] commas in ctor-init-lists

On Wednesday 01 June 2016, Marc Mutz wrote:
> Hi,
>
> There seems to have been a silent underground move to uglify the Qt sources
> , by using commas to introduce lines
> . I have no idea where this came from
>
I am probably one of those introducing it since it comes from WebKit coding
style. Sorry, I also think it is kind of ugly, but it is very structurally
clean and in some circumstances I prefer it due to that.

Note there is a related coding style violation for if statements.

if (blabla
   || lala
   || justDoIt) {
   doIt();
}

This has the same benefits for diffs as the leading comma, though I mainly use
it to avoid the sub-expressions of the if statements to indent the same as
statements inside the if-block. This helps again make the code faster and
easier to read at glance, though it violates Qt coding style.

`Allan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread Allan Sandfeld Jensen

On Wednesday 01 June 2016, Marc Mutz wrote:
> Hi,
> 
> There seems to have been a silent underground move to uglify the Qt sources
> , by using commas to introduce lines
> . I have no idea where this came from
> 
I am probably one of those introducing it since it comes from WebKit coding 
style. Sorry, I also think it is kind of ugly, but it is very structurally 
clean and in some circumstances I prefer it due to that.

Note there is a related coding style violation for if statements.

if (blabla 
   || lala
   || justDoIt) {
   doIt();
}

This has the same benefits for diffs as the leading comma, though I mainly use 
it to avoid the sub-expressions of the if statements to indent the same as 
statements inside the if-block. This helps again make the code faster and 
easier to read at glance, though it violates Qt coding style.

`Allan
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread Mandeep Sandhu

>
> Why would anyone bother to count votes before any (theoretically binding
> or non-binding, doesn't seem to matter) result of voting gets ignored by
> the next submitter anyway?

I think the votes are meant for 'ratifying' the coding guidelines. And
the hope that submitters _will_ follow the rules mentioned there.
If not following the guidelines is a common occurrence, then that
warrants a separate discussion.

-mandeep

>
> Andre'
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread André Pönitz

On Wed, Jun 01, 2016 at 02:57:27PM +0200, Dominik Holland wrote:
> +1 for changing they coding style

-1 for anything that's not applied uniformly within a reasonably short
time to the whole codebase.

More often than not I really don't care too much *what* the change is,
but I am getting sick of seeing more and more ways being introduced to
express the same thing within the same module, or even within the same
file.

I appreciate that it sometimes spares me from running a 'git blame',
because it's rather clear who touched the code last and what time that
was approximately, but overall I am very much in favour of a *uniform*
code base, and I'd pretty much prefer to *not* know who wrote a certain
stanza before running 'git blame'.

Since we are at the topic of "ongoing underground movements":

IMNSHO there is by now way too much of that going on, and that's not
only about coding style in a few .cpp, but also about general design
patterns used and public API.

For me, covenient and reasonably uniform API and implementation used to
be Qt's second major selling point besides platform independence. Right
now I believe that "underground movements" and the current system of
any approximately two out of a few hundred people being able to change
random bits to random values does not work into the direction of
preserving that.

>From the four possible combinations of
  { "people stick to agreed rules" , "people play around" } x
  { "lots of people can submit", "tightly controled approval" }
the "people play around"-and-"lots of people can submit" case
is the least viable one long term.

Andre'

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread Marc Mutz

On Thursday 02 June 2016 13:17:45 Martin Smith wrote:
> >The two space indented colon in the coding style is even more awkward,
> >having to manually indent the colon instead of using the editor's tab
> >feature, plus it breaks the "put things at the end rule".
> 
> emacs has handled it correctly for me for at least two decades.

As does QtC, of course, for as long as it exists.

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread Martin Smith


>The two space indented colon in the coding style is even more awkward, having 
>to
>manually indent the colon instead of using the editor's tab feature, plus it 
>breaks the
>"put things at the end rule".

emacs has handled it correctly for me for at least two decades. I just hit 
return it goes to the correct column. In fact, emacs handles it correctly 
whether I put the colon after the paren or on the next line.

martin

From: Development <development-bounces+martin.smith=qt...@qt-project.org> on 
behalf of Tor Arne Vestbø <tor.arne.ves...@qt.io>
Sent: Thursday, June 2, 2016 1:07:27 PM
To: Simon Hausmann; Marc Mutz; development@qt-project.org
Subject: Re: [Development] commas in ctor-init-lists

On 01/06/16 14:56, 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 and I find that it makes
> diffs easier to read.

+2

Bar::Bar(Bla *b)
 : Foo(b)
 , m_baz(123)
 , m_biz(321)
{
}

aligns and reads much easier (in both diffs and code) than:

Bar::Bar(Bla *b) :
 Foo(b),
 m_baz(123),
 m_biz(321)
{
}

especially recognizing the baseclass-init over member init. The two
space indented colon in the coding style is even more awkward, having to
manually indent the colon instead of using the editor's tab feature,
plus it breaks the "put things at the end rule".

Bar::Bar(Bla *b)
   : Foo(b),
 m_baz(123),
 m_biz(321)
{
}

tor arne



>
> Simon
>
>
> 
> *From:* Marc Mutz <marc.m...@kdab.com>
> *Sent:* Jun 1, 2016 14:41
> *To:* development@qt-project.org
> *Subject:* [Development] commas in ctor-init-lists
>
> Hi,
>
> There seems to have been a silent underground move to uglify the Qt sources
> , by using commas to introduce lines
> . I have no idea where this came from
> , but it looks butt
> -ugly and it is in violation of http
> ://wiki
> .qt
> .io
> /Qt_Coding_Style
>
> QFoo::QFoo()
>   : QBase(),
> m_f1(),
> m_f2()
> {
>
> }
>
> -not-
>
> QFoo::QFoo()
>   : QBase()
>   , m_f1()
>   , m_f2()
> {
>
> }
>
> (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the
> _end_ of wrapped lines")
>
> Thanks,
> Marc
>
> --
> Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread Tor Arne Vestbø


On 01/06/16 14:56, 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 and I find that it makes
diffs easier to read.


+2

Bar::Bar(Bla *b)
: Foo(b)
, m_baz(123)
, m_biz(321)
{
}

aligns and reads much easier (in both diffs and code) than:

Bar::Bar(Bla *b) :
Foo(b),
m_baz(123),
m_biz(321)
{
}

especially recognizing the baseclass-init over member init. The two 
space indented colon in the coding style is even more awkward, having to 
manually indent the colon instead of using the editor's tab feature, 
plus it breaks the "put things at the end rule".


Bar::Bar(Bla *b)
  : Foo(b),
m_baz(123),
m_biz(321)
{
}

tor arne





Simon



*From:* Marc Mutz 
*Sent:* Jun 1, 2016 14:41
*To:* development@qt-project.org
*Subject:* [Development] commas in ctor-init-lists

Hi,

There seems to have been a silent underground move to uglify the Qt sources
, by using commas to introduce lines
. I have no idea where this came from
, but it looks butt
-ugly and it is in violation of http
://wiki
.qt
.io
/Qt_Coding_Style

QFoo::QFoo()
  : QBase(),
m_f1(),
m_f2()
{

}

-not-

QFoo::QFoo()
  : QBase()
  , m_f1()
  , m_f2()
{

}

(http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the
_end_ of wrapped lines")

Thanks,
Marc

--
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread Konstantin Tokarev



01.06.2016, 15:41, "Marc Mutz" :
> Hi,
>
> There seems to have been a silent underground move to uglify the Qt sources
> , by using commas to introduce lines
> . I have no idea where this came from

It's codified by WebKit coding style, and many people here have contributed to 
QtWebKit:

https://webkit.org/code-style-guidelines/#other-punctuation


> , but it looks butt
> -ugly and it is in violation of http
> ://wiki
> .qt
> .io
> /Qt_Coding_Style
>
> QFoo::QFoo()
>   : QBase(),
> m_f1(),
> m_f2()
> {
>
> }
>
> -not-
>
> QFoo::QFoo()
>   : QBase()
>   , m_f1()
>   , m_f2()
> {
>
> }
>
> (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the
> _end_ of wrapped lines")
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-02 Thread Julien Blanc

Le mercredi 01 juin 2016 à 15:36 +0200, Olivier Goffart a écrit :


> 
> Anyone has a config file for clang-format to use with qt so it can be used 
> with git-clang-format?
> 


This is the most relevant question in this kinda trollish kind of topic.

Everyone has different opinion on these matters, and, this is more a
matter of style / habits than real arguments. But there’s one thing that
matters a lot more than code style itself : consistency.

But to go back to the topic, we’re in 2016 now, and still we face the
same discussions as in the nineties. Why is that that I can’t work with
the code the way *I* want, and share it with the others the way *they*
want. Hey, we now have really pretty decent tools to reformat code !
What i have in mind is something like :

- post-checkout/clone git hook that reformat code to *my* style when i
work on it
- pre-commit hook that reformat code to the *neutral* (ie, qt style
rules) style when committing
- difftool customization so that diff are displayed in my style rather
than the neutral one
- server-side : style is checked in the pre-commit hook, either it is
reformatted automatically or rejected if not in the good format.

Never had the time to play with something like that, i’m wondering if
someone ever did, and in that case what’s working and what’s not, the
issues faced.

Regards,

Julien
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

2016-06-01 Thread Philippe

> The leading comma's are also helpful if we have some part of the
> initializer list protected by a preprocessor conditional (or might be
> needed in the future).

This is right.
This is what CLangFormat proposed me by default.
I thought is was a bit strange when I started to use this, but now I
would not change.

Philippe

On Wed, 1 Jun 2016 16:10:34 -0700
Mandeep Sandhu  wrote:

> The leading comma's are also helpful if we have some part of the
> initializer list protected by a preprocessor conditional (or might be
> needed in the future).
> 
> QFoo::QFoo()
>   : QBase()
>   , m_f1()
> #ifdef XYZ
>   , m_f2()
> #endif
>   , m_f3()
> 
> Although I'm not sure if we have many (of any at all) such instances
> in the Qt source.
> 
> But this form does take some getting used to. My natural tendency is
> to put the comma at the end.
> 
> Just my 2¢.
> 
> -mandeep
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

On quarta-feira, 1 de junho de 2016 21:05:09 BRT Thiago Macieira wrote:
> On quarta-feira, 1 de junho de 2016 15:49:20 BRT Jędrzej Nowacki wrote:
> >  Btw. How often do you
> > 
> > _read_ commas? My brain automatically skips them... In the end it simply
> > doesn't matter much.
> 
> Quite often. There's this author I'm reading that often forgets commas when
> writing things like:
>   "it should be easy to convince people of the importance of that Thiago
>   thought" (comma missing before "Thiago thought")

Oh, I forgot to say: a comma can save a life.

Let's eat Grandma
Let's eat, Grandma

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

On quarta-feira, 1 de junho de 2016 12:56:12 BRT 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 and I find that it makes diffs
> easier to read.

I object to that, I have rejected patches to QtCore that add code like that 
and I have even fixed the coding style for patches that were approved by others 
without my knowledge, as is my prerrogative as maintainer.

Gerrit show intra-line differences, so it's easy to spot the comma moving.

The trick for enums is to always place last an enum with a special value.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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

On quarta-feira, 1 de junho de 2016 15:06:16 BRT Mark Gaiser wrote:
> The "butt-ugly" style looks more readable to me.
> And imho it reduces the possibility of forgetting a forgetting a comma in
> the begin since then your arguments will look out of alignment.

The compiler won't let you forget, so that's not an argument.

> Funny in the coding style you mention. For operators: "An operator at the
> end of the line is easy to miss if the editor is too narrow." The exact
> same could be said for commas at the end of the line.

I don't like the rule of placing operators at the beginning of the next line. 
I prefer it at the end, which indicates to the reader that the line continues, 
as it doesn't end in either ) or semi-colon.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

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