Re: Updating our coding conventions and coding style for C++11
Hi, On 16/01/20 18:46, Kai Uwe Broulik wrote: > Hi, > > for "auto" I think we should always annotate it with const, *, and/or & > where appropriate: > > auto *something = new MyCustomType; > auto *keyEvent = static_cast(event); IMHO the * here is redundant and only adds noise. It's clear that `something` is a MyCustomType* and that `keyEvent` is a QKeyEvent*. > auto &barRef = foo[bar]; This could be helpful indeed. > Cheers > Kai Uwe Cheers, Elvis
Re: Updating our coding conventions and coding style for C++11
On 1/17/20 12:27 AM, David Faure wrote: > On jeudi 16 janvier 2020 18:29:11 CET Vlad Zahorodnii wrote: >> I would like us to copy Qt's policy [1] for consistency: > > OK, please do. Done. Please notice that I did not annotate auto keywords with '*'. Once we have an official policy, we can fix coding style in those code samples. Cheers, Vlad
Re: Updating our coding conventions and coding style for C++11
On 1/16/20 7:29 PM, Vlad Zahorodnii wrote: > The common practice used in KDE seems to be: > > for (a:b) Alright, it looks like we all agree on this one, so I'm going to update the Frameworks Coding Style.
Re: Updating our coding conventions and coding style for C++11
On 1/16/20 7:46 PM, Kai Uwe Broulik wrote: > for "auto" I think we should always annotate it with const, *, and/or & > where appropriate: > > auto *something = new MyCustomType; > auto *keyEvent = static_cast(event); > const auto myList = QStringList({QLatin1String("FooThing"), > QLatin1String("BarThing")}); > auto &barRef = foo[bar]; I also prefer to do that. On the other hand, I'd like our code to be as close as possible to Qt's code in terms of coding style. Perhaps, this discussion must be moved to the Qt/Development mailing list unless the question of annotating auto with const/*/& had been raised before there. Cheers, Vlad
Re: Updating our coding conventions and coding style for C++11
On 1/17/20 12:46 AM, Kai Uwe Broulik wrote: > It provides useful visual information. > > auto foo = bar(); > auto baz = &bla; I don't think that you should use auto in either case since it's not clear what type foo and baz have. Cheers, Vlad
Re: Updating our coding conventions and coding style for C++11
On Thu, 16 Jan 2020, 22:46 Kai Uwe Broulik, wrote: > > > Well, the * is completely redundant in those cases, so it doesn't bring > anything. > > I'd be tempted to say, let's not require it. > > But then it raises the question of consistency (without a guideline, > we'll have some places with * and some places without *). > > It provides useful visual information. > > auto foo = bar(); > auto baz = &bla; > Neither of those examples abide by the proposed Qt/Vlad rules, which I think would render your issue moot. I don't think I really understand your potential issue anyway, if you tried to use baz form and it wasn't the type I expected it just wouldn't compile? This is somewhat different to the case where have you have overloaded & and non& operators, such as [] where I do I understand why it's useful. I'll continue mandating that in code I maintain, even if it's not > official policy. > The context of this original email being sent was that I got extremely frustrated with per-project seemingly random rules. I can happily follow a global policy even if I don't agree with it, but we need to define things. Otherwise, we'll end up in this situation again. David
Re: Updating our coding conventions and coding style for C++11
Am Donnerstag, 16. Januar 2020, 23:27:57 CET schrieb David Faure: > On jeudi 16 janvier 2020 18:29:11 CET Vlad Zahorodnii wrote: > > I would like us to copy Qt's policy [1] for consistency: > OK, please do. +1, thanks for the initiative, Vlad. > Kai-Uwe wrote: > > for "auto" I think we should always annotate it with const, *, and/or & > > where appropriate: > > auto *something = new MyCustomType; > > auto *keyEvent = static_cast(event); > > Well, the * is completely redundant in those cases, so it doesn't bring > anything. I'd be tempted to say, let's not require it. > But then it raises the question of consistency (without a guideline, we'll > have some places with * and some places without *). By my own experience so far I would also settle to say, redundant but very helpful to human readers who try to understand some unknown code. So my +1 for requiring explicit pointer & reference & const with auto. This is information too often important for understanding the rest of the code to just rely on the human to extract that from the variable initialization code, code is much faster to read with that info being explicit. And sometimes it can also help the code writer to be more sure their intention/understanding it matched. And after all "const", "*" & "&" are not that expensive to type or bloating up the line :) More, if you always write them, you will not forget to do so where they are not redundant. Cheers Friedrich
Re: Updating our coding conventions and coding style for C++11
On Thursday 16 Jan 2020 18:46:06 Kai Uwe Broulik wrote: > Hi, > > for "auto" I think we should always annotate it with const, *, and/or & > where appropriate: > > auto *something = new MyCustomType; > auto *keyEvent = static_cast(event); > const auto myList = QStringList({QLatin1String("FooThing"), > QLatin1String("BarThing")}); This is a bad example of the use of auto. It can be more simply written without using auto: const QStringList myList{QLatin1String("FooThing"), QLatin1String("BarThing")}; > auto &barRef = foo[bar]; > > > The common practice used in KDE seems to be: > > for (a:b) > > +1 > > Cheers > Kai Uwe -- David Jarvie. KDE developer. KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Updating our coding conventions and coding style for C++11
Well, the * is completely redundant in those cases, so it doesn't bring anything. I'd be tempted to say, let's not require it. But then it raises the question of consistency (without a guideline, we'll have some places with * and some places without *). It provides useful visual information. auto foo = bar(); auto baz = &bla; where's the pointer now? Sure, your IDE probably will autocomplete operator-> as needed but to me it just feels odd, visually. In any case, I'll continue mandating that in code I maintain, even if it's not official policy. Though I also thought the reference would be implied by auto but apparently it is not. Cheers Kai Uwe
Re: Updating our coding conventions and coding style for C++11
On jeudi 16 janvier 2020 18:29:11 CET Vlad Zahorodnii wrote: > I would like us to copy Qt's policy [1] for consistency: OK, please do. > for (a:b) +1 Kai-Uwe wrote: > for "auto" I think we should always annotate it with const, *, and/or & > where appropriate: > auto *something = new MyCustomType; > auto *keyEvent = static_cast(event); Well, the * is completely redundant in those cases, so it doesn't bring anything. I'd be tempted to say, let's not require it. But then it raises the question of consistency (without a guideline, we'll have some places with * and some places without *). >From Qt: examples/widgets/gallery/widgetgallery.cpp:272:auto toolMenu = new QMenu(menuToolButton); tests/manual/cocoa/menurama/main.cpp:40:auto *dockMenu = new QMenu(); Personally, I can survive with this small discrepancy, just like the Qt developers clearly can as well. But if everyone feels strongly that we need to standardize on something > const auto myList = QStringList({QLatin1String("FooThing"), > QLatin1String("BarThing")}); > auto &barRef = foo[bar]; I agree about those, they are not redundant. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: Updating our coding conventions and coding style for C++11
Hi, for "auto" I think we should always annotate it with const, *, and/or & where appropriate: auto *something = new MyCustomType; auto *keyEvent = static_cast(event); const auto myList = QStringList({QLatin1String("FooThing"), QLatin1String("BarThing")}); auto &barRef = foo[bar]; The common practice used in KDE seems to be: for (a:b) +1 Cheers Kai Uwe
Updating our coding conventions and coding style for C++11
Hi, I would like to update our coding conventions https://community.kde.org/Policies/Library_Code_Policy. The auto keyword is not mentioned leading to it being a common point of contention in reviews as we can't point to a reference. I would like us to copy Qt's policy [1] for consistency: Optionally, you can use the auto keyword in the following cases. If in doubt, for example if using auto could make the code less readable, do not use auto. Keep in mind that code is read much more often than written. When it avoids repetition of a type in the same statement. auto something = new MyCustomType; auto keyEvent = static_cast(event); auto myList = QStringList() << QLatin1String("FooThing") << QLatin1String("BarThing"); When assigning iterator types. auto it = myList.const_iterator(); In addition to the coding conventions, I would like to update the KDE Frameworks Coding Style to include a statement about whitespace before range-based for loop colons. The common practice used in KDE seems to be: for (a:b) Cheers, vlad [1] https://wiki.qt.io/Coding_Conventions#auto_Keyword