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
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
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
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
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
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 -Qt::TextFormat textformat; -Qt::TextInt
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
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
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 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 on > behalf of Martin Smith > 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 capabl
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 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 on > behalf of Martin Smith > 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
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 on behalf of Martin Smith 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 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 on behalf of André Somers 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 on behalf of Allan Sandfeld Jensen 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
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
> > 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
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? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
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
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
>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 on behalf of Tor Arne Vestbø 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 > *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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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 *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
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
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
> 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
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") And *every* time I read a sentence like that, I stop and cringe. There are some sentences that you also have to stop and think about what the author meant. Excess commas are also bad. I remember reading some text by Sune once (I think it was in Danish) and found it really weird the placement of commas, making me stop where the sentence structure didn't in my mind call for it. -- 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
And another +1 cu Robert On 01.06.2016 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. 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 -- Robert Griebl Senior Software Engineer Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.gri...@pelagicore.com www.pelagicore.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
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
Re: [Development] commas in ctor-init-lists
On 6/1/16, 5:27 PM, "Development on behalf of Marc Mutz" wrote: ... >Semicolons and commas are visually *designed* to be >trailing. And consequently every C++ text book uses trailing commas. The pros that have been cited include code review and diffs for leading commas. One nice thing about books is that they are fairly static, so the pro doesn’t really apply ;-) I thought it looked strange at first, and was weird to use for about a day. But when the code changes, it comes in pretty handy. Now I’ve found I like the approach. My $.02. Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On Wednesday 01 June 2016 16:33:39 Sergio Martins wrote: > On Wednesday, 1 June 2016 15:44:22 WEST Marc Mutz wrote: > > On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: > > > Subjective reasons against leading commas: > > > - It's ugly > > > > > > Subjective reasons against trailling commas: > > > - It's ugly > > > > I beg your pardon? Trailing commas are ugly? So where's the text editor > > that folds prose text to have commas on the next line? > > What does prose text have to do with C++ ? When people say readable code > resembles english it's not about punctuation. It just means you can > understand the business logic by reading the variable and function names: > > while (isSick) { eatApples(); } > > You're pushing the analogy too far. I don't think so. Semicolons and commas are visually *designed* to be trailing. And consequently every C++ text book uses trailing commas. Not even GNU style dares to tread there. Seeing leading commas just hurts visually, and they are not idiomatic C++. To a C++ programmer, they look alien, out of place. That is not the case with whitespace, or where to put braces, because there is corresponding variance in the C++ text books, too. But there is no variance in comma placement. *All* C++ text books use trailing commas. > > > - You can comment it out by commenting only 1 line > > > - Code generators / tooling only have to touch 1 line to add or remove > > > > All these are also valid for enums and function argument lists, but I see > > no- one doing similar things for enums and functions. > > What does function arguments have to do with ctor-init-lists ? What do they *not* have to do with each other? They are both comma-separated, and often need line wrapping to fit within the given column limit. Functions also may have parameters that are absent in conditional compilation. Functions are used more often and tend to have longer expressions as arguments than ctor-init-list entries, making such problems as cited for ctor-init-lists more frequent in functions than in ctor-init-lists. > The number > of member variables to initialize scales linearly with the number of > features, can you say the same about functions ? I dispute that. A class that has more than five semantically-different data members smells just as strongly as a function that has five arguments. > Do you keep growing your > function until you have 10 or 20 arguments ? I don't care about commas in > functions, I refactor the function instead. And I'd refactor the class, too. > Agreed about enums, but I write a order of magnitude more ctors than enums, > so never felt motivated to use C++11 trailling enum feature. Well, and we all write an order of magnitude more functions than ctors, so why come we never use the same comma rule as for ctor-init-lists? We instead write the same function twice, cf. QTemporaryFile ctors vs. QT_NO_QOBJECT. Why? Because it's *ugly*. NSDMI and ctor delegation will solve most of this, btw, for ctor-init-lists (but not functions). It seems to me that people are arguing that a problem exists in a construct used X times (ctor-init-lists), and the same problem does not exist in a construct used 10X times (functions) per unit code. Either be consequent about it, and demand the same (the ugly) comma placement for function arguments and enums, or acknowledge that the reasons cited for using leading commas in ctor-init-lists are applicable to functions and enums, too, and, seeing no problem there, are thus no problem in ctor-init-lists, either. Otherwise, this is nothing more than arguing for some random, inconsistent, style-of-the-day, just because some Nokia-era modules happen to use it in violation of the Qt Coding Style, QtBase and C++ text books existing practice. 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
And another +1 from me. -- Robin Burchell On Wed, Jun 1, 2016, at 09:23 PM, Andy Nichols wrote: > +1 to specify the coding style to be the "butt ugly" one. > > I'm one of those who has (not so secretly) been committing and approving > the offending style after all ;-) Though for the record I did not think > it mattered and was not covered by the style guideline you cited. > > Andy Nichols > > > On 01 Jun 2016, at 14:56, Simon Hausmann wrote: > > > > 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 > ___ > 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
+1 to specify the coding style to be the "butt ugly" one. I'm one of those who has (not so secretly) been committing and approving the offending style after all ;-) Though for the record I did not think it mattered and was not covered by the style guideline you cited. Andy Nichols > On 01 Jun 2016, at 14:56, Simon Hausmann wrote: > > 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On 01/06/2016 18:12, Mathias Hasselmann wrote: > Yes, when it comes to initializer lists the trailing comma looks ugly to > me. Because of the inconsistent two-space indent for the first > initializer. Because line starts of are not aligned. In my projects I use this style: MyObject::MyObject(): SuperClass(), m_var1(), m_var2() { } Having a diff taking two lines never annoyed me, especially given that often the last member is either d_ptr() or q_ptr(), so I usually add members in the middle. > Not mentioned yet: Conditional compilation vs. stable ABI: > > MamanBar::MamanBar(...) > : m_field1(...), > m_field2(...),// oh... > #ifdef FEATURE1_ENABLED > m_field3(...), // ...ah > #endif > #ifdef FEATURE2_ENABLED > m_field4(...) > #endif > { > } You can always find cases which break with either style. MamanBar::MamanBar(...) #ifdef FEATURE1_ENABLED : m_field1(...) // ...ah #endif , m_field2(...) , m_field3(...) { } Ultimately, it's just a matter of personal preferences; people like to argue about diff size or better spotting of obvious mistakes (when putting operators at the beginning of the line), while as a matter of fact people can live perfectly well and be equally productive with either style. Ciao, Alberto ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
In previous projects I have worked on, the "leading comma" was done because it makes it easier if you have #ifdef'ed variables that need initialization. You are less likely to introduce a syntax error when the defined variable is not set.. Ie, the first one causes a syntax error QFoo::QFoo() : QBase(), m_f1(), #ifdef USE_F2 m_f2() #endif { } Whereas the second does not QFoo::QFoo() : QBase() , m_f1() #ifdef USE_F2 , m_f2() #endif { } -Original Message- From: Development [mailto:development-bounces+scott=towel42@qt-project.org] On Behalf Of Marc Mutz Sent: Wednesday, June 1, 2016 5:42 AM 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
Re: [Development] commas in ctor-init-lists
Am 01.06.2016 um 15:15 schrieb Sergio Martins: On Wednesday, 1 June 2016 14:41:30 WEST 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 , but it looks butt -ugly and it is in violation of http (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the _end_ of wrapped lines") I think that refers to function calls and wasn't written with ctor init-lists in mind, but we can improve it so it stops being a violation. Subjective reasons against leading commas: - It's ugly Subjective reasons against trailling commas: - It's ugly Objective reasons in favor of leading commas: - You get 1 line diffs - You can comment it out by commenting only 1 line - Code generators / tooling only have to touch 1 line to add or remove Not mentioned yet: Conditional compilation vs. stable ABI: MamanBar::MamanBar(...) : m_field1(...), m_field2(...),// oh... #ifdef FEATURE1_ENABLED m_field3(...),// ...ah #endif #ifdef FEATURE2_ENABLED m_field4(...) #endif { } Ciao, Mathias -- Mathias Hasselmann | mathias.hasselm...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
First of all: Thank you Marc for raising that topic. Actually it also concerned me quite often, but so far I was to shy to mention this very opinionated topic. Am 01.06.2016 um 15:44 schrieb Marc Mutz: > On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: >> On Wednesday, 1 June 2016 14:41:30 WEST 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've seen it first at Nokia, but it might be older. Reasoning was to minimize patches and to reduce chance of merge conflicts. >>> , but it looks butt Which is highly subjective. >>> -ugly and it is in violation of http >>> (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at >>> the _end_ of wrapped lines") >> >> I think that refers to function calls and wasn't written with ctor >> init-lists in mind, but we can improve it so it stops being a violation. > > I'm pretty sure it was written with ctor-init-lists in mind, because all of > QtBase uses trailing comma. I only come across the leading comma version in > new modules. > >> Subjective reasons against leading commas: >> - It's ugly >> >> Subjective reasons against trailling commas: >> - It's ugly > > I beg your pardon? Trailing commas are ugly? So where's the text editor that > folds prose text to have commas on the next line? Now as we are at bike-sheding: Yes, when it comes to initializer lists the trailing comma looks ugly to me. Because of the inconsistent two-space indent for the first initializer. Because line starts of are not aligned. Lets proceed with smart-assing: Trailing comma violates two very explicit rules: - operators start at the beginning of the new lines - 4 spaces are used for indentation Leading comma: - fixes those style violations - reduces patch noise - reduces inconsistent - at the cost of maybe violating one rule with unclear scope ("commas go at the end of wrapped lines") I for my part prefer leading comma. > Yes, and we should wait for / propose that they do the same change for ctor- > init-list, too. Not apply some horrible work-around. By your choice of wording you seem rather upset. For myself I know that I feel upset when my comfort zone gets violate, when someone tries to changes things I grew comfortable with. How are the chances that you are upset just for the very same reason? Ciao, Mathias -- Mathias Hasselmann | mathias.hasselm...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
+1 from me as well. The argument about natural language makes no sense to me; Nothing in C++ resembles natural grammar, nor should it; It might take some getting used to, like any change in style, but after a while you won't think it is ugly anymore, and then we can reap the benefits of it being objectively superior because it minimizes diffs in initializer lists. :) -- Eskil Abrahamsen Blomfeldt Senior Manager, Qt Graphics/Multimedia The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfe...@qt.io<mailto:eskil.abrahamsen-blomfe...@qt.io> http://qt.io<http://qt.io/> From: Development mailto:development-bounces+eskil.abrahamsen-blomfeldt=qt...@qt-project.org>> on behalf of Simon Hausmann mailto:simon.hausm...@qt.io>> Date: Wednesday 1 June 2016 at 14:56 To: Marc Mutz mailto:marc.m...@kdab.com>>, "development@qt-project.org<mailto:development@qt-project.org>" mailto:development@qt-project.org>> Subject: Re: [Development] commas in ctor-init-lists 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 From: Marc Mutz mailto:marc.m...@kdab.com>> Sent: Jun 1, 2016 14:41 To: development@qt-project.org<mailto: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 mailto: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<mailto: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
Jędrek remarked: >> argument about how similar code is to natural language is a bit odd >> to me, I'm not aware of any successful programing language that >> simulates natural grammar :-) . On 1st June 2016 at 16:17 Konstantin Tokarev added to the discussion: > For example, Perl is somewhat closer to it than C++, it's designed by > linguist after all. I suspect Jędrek was aware of this and actively meant to insinuate something about whether perl is a "successful programing language". For my own part, although I do enjoy perl's scope for poetic choices about how to phrase things, I must confess its linguistic pretensions mostly lead to programmers, who *haven't* thought carefully about the future readers of their code, writing code that's made harder to read. The freedom to express things in Tim Toady's many ways does make it possible to write elegant and poetic perl, but most programmers are lousy poets in too much of a hurry to hack something together to worry about elegance. Much as may be said for the natural language we write. In any case, C++ isn't perl and doesn't come close to it in terms of naturality of linguistic form. C++ isn't even Algol, in which multi-word identifiers were allowed to embed (ignored) spaces, making camelCase redundant. So whether C++ reads, or is typeset, like English is far less important than whether it is easy to see, at a glance, whether it is correct. As to commas normally appearing at the end of prior text: where I learned my anglic, colons do the same - yet we quite commonly split a class constructor just before the colon, that introduces the initialization before the body, rather than just after it. Doing the same for the comma-joined subsequent initializer list is no worse - and arguably at least consistent with the treatment of the colon. As to that, I can see why some like the comma-first style (and I notice emacs does a decent job of indenting it sensibly), although I don't really see a huge win in either direction and my eyes parse each with roughly equal ease. Speaking of colons, one coder's "butt-ugly" is another's "callipygian", I guess, Eddy. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On Wednesday, 1 June 2016 15:44:22 WEST Marc Mutz wrote: > On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: > > Subjective reasons against leading commas: > > - It's ugly > > > > Subjective reasons against trailling commas: > > - It's ugly > > I beg your pardon? Trailing commas are ugly? So where's the text editor that > folds prose text to have commas on the next line? What does prose text have to do with C++ ? When people say readable code resembles english it's not about punctuation. It just means you can understand the business logic by reading the variable and function names: while (isSick) { eatApples(); } You're pushing the analogy too far. > > > - You can comment it out by commenting only 1 line > > - Code generators / tooling only have to touch 1 line to add or remove > > All these are also valid for enums and function argument lists, but I see > no- one doing similar things for enums and functions. What does function arguments have to do with ctor-init-lists ? The number of member variables to initialize scales linearly with the number of features, can you say the same about functions ? Do you keep growing your function until you have 10 or 20 arguments ? I don't care about commas in functions, I refactor the function instead. Agreed about enums, but I write a order of magnitude more ctors than enums, so never felt motivated to use C++11 trailling enum feature. Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
01.06.2016, 16:50, "Jędrzej Nowacki" : > On Wednesday 01 of June 2016 15:16:01 Andreas Aardal Hanssen wrote: >> > Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser : >> > ... >> > 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. >> Silly point, it's pretty much a given that there is a comma there, it's >> insignificant. But the precise operator makes all the difference. >> >> +1 Marc, who cares if the diff is shorter or easier to read if the _code_ is >> hard to read. And butt-ugly code is hard to read. Code is easiest to read >> if it resembles English , and commas at the beginning of a line just >> doesn't. >> >> Andreas >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > Yey for coding style fights! > > I care about easy to read diffs and not every butt is ugly :-) These days I'm > probably reading more code then English literature (which is definitely > visible > in my mails and commit messages...) and argument about how similar code is to > natural language is a bit odd to me, I'm not aware of any successful > programing language that simulates natural grammar :-) . For example, Perl is somewhat closer to it than C++, it's designed by linguist after all. > Btw. How often do you > _read_ commas? My brain automatically skips them... In the end it simply > doesn't matter much. > > Cheers, > Jędrek > > ___ > 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
On Wednesday 01 of June 2016 15:44:22 Marc Mutz wrote: > > Subjective reasons against trailling commas: > > - It's ugly > > I beg your pardon? Trailing commas are ugly? So where's the text editor > that folds prose text to have commas on the next line? Aesthetics are subjective by definition, you could argue that leading commas are creating optically aligned result, highlighting indentation of the initialization list :D > > Objective reasons in favor of leading commas: > > - You get 1 line diffs > > You get the same when you insert fields in the middle. Only at the end > there's a difference. You can not always pick where you insert new field, it may cause warnings and bugs cause by wrong initialization order. > > - You can comment it out by commenting only 1 line > > - Code generators / tooling only have to touch 1 line to add or remove > > All these are also valid for enums and function argument lists, but I see > no- one doing similar things for enums and functions. > > If those reasons were strong enough to do away with 100s of years of > typesetting history, why don't we use it for functions, too: > >func( > loongarg1 >, lnerarg2 >, looongestarg3 > ); > > Hmm, sweet... Good idea we should all that everywhere :-) > > Weren't these reasons even a motivation for C++11 to support "trailling > > enum comma" ? > > Yes, and we should wait for / propose that they do the same change for ctor- > init-list, too. Not apply some horrible work-around. We have long tradition of doing stuff before C++ standard. We can not just drop it :P Enough trolling :-) Cheers , Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On Wednesday 01 of June 2016 15:16:01 Andreas Aardal Hanssen wrote: > > Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser : > > ... > > 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. > Silly point, it's pretty much a given that there is a comma there, it's > insignificant. But the precise operator makes all the difference. > > +1 Marc, who cares if the diff is shorter or easier to read if the _code_ is > hard to read. And butt-ugly code is hard to read. Code is easiest to read > if it resembles English , and commas at the beginning of a line just > doesn't. > > Andreas > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Yey for coding style fights! I care about easy to read diffs and not every butt is ugly :-) These days I'm probably reading more code then English literature (which is definitely visible in my mails and commit messages...) and argument about how similar code is to natural language is a bit odd to me, I'm not aware of any successful programing language that simulates natural grammar :-) . Btw. How often do you _read_ commas? My brain automatically skips them... In the end it simply doesn't matter much. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: > On Wednesday, 1 June 2016 14:41:30 WEST 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 > > , but it looks butt > > -ugly and it is in violation of http > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at > > the _end_ of wrapped lines") > > I think that refers to function calls and wasn't written with ctor > init-lists in mind, but we can improve it so it stops being a violation. I'm pretty sure it was written with ctor-init-lists in mind, because all of QtBase uses trailing comma. I only come across the leading comma version in new modules. > Subjective reasons against leading commas: > - It's ugly > > Subjective reasons against trailling commas: > - It's ugly I beg your pardon? Trailing commas are ugly? So where's the text editor that folds prose text to have commas on the next line? > Objective reasons in favor of leading commas: > - You get 1 line diffs You get the same when you insert fields in the middle. Only at the end there's a difference. > - You can comment it out by commenting only 1 line > - Code generators / tooling only have to touch 1 line to add or remove All these are also valid for enums and function argument lists, but I see no- one doing similar things for enums and functions. If those reasons were strong enough to do away with 100s of years of typesetting history, why don't we use it for functions, too: func( loongarg1 , lnerarg2 , looongestarg3 ); Hmm, sweet... > Weren't these reasons even a motivation for C++11 to support "trailling > enum comma" ? Yes, and we should wait for / propose that they do the same change for ctor- init-list, too. Not apply some horrible work-around. 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 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! Also there was some talk about optionally allowing braces for single line if (more similar to KDE style, less diff, and avoid "goto fail" kind of problem) Anyone has a config file for clang-format to use with qt so it can be used with git-clang-format? -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On Wednesday, June 1, 2016 12:56:12 PM 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. +1, less diff noise when an initializer is added/removed -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
> Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser : > ... > 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. Silly point, it's pretty much a given that there is a comma there, it's insignificant. But the precise operator makes all the difference. +1 Marc, who cares if the diff is shorter or easier to read if the _code_ is hard to read. And butt-ugly code is hard to read. Code is easiest to read if it resembles English , and commas at the beginning of a line just doesn't. Andreas ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On Wednesday, 1 June 2016 14:41:30 WEST 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 > , but it looks butt > -ugly and it is in violation of http > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") I think that refers to function calls and wasn't written with ctor init-lists in mind, but we can improve it so it stops being a violation. Subjective reasons against leading commas: - It's ugly Subjective reasons against trailling commas: - It's ugly Objective reasons in favor of leading commas: - You get 1 line diffs - You can comment it out by commenting only 1 line - Code generators / tooling only have to touch 1 line to add or remove Weren't these reasons even a motivation for C++11 to support "trailling enum comma" ? Regards, -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
On Wed, Jun 1, 2016 at 2:41 PM, 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 > , 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 > > 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. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
+1 for changing they coding style Am 06/01/2016 um 02:56 PM schrieb Simon Hausmann: > 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 > > > > *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 > -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holl...@pelagicore.com www.pelagicore.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] commas in ctor-init-lists
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 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] 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