Re: Updating our coding conventions and coding style for C++11

2020-01-19 Thread Elvis Angelaccio
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  = foo[bar];

This could be helpful indeed.

> Cheers
> Kai Uwe

Cheers,
Elvis


Re: Updating our coding conventions and coding style for C++11

2020-01-17 Thread Vlad Zahorodnii
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

2020-01-17 Thread Vlad Zahorodnii
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

2020-01-17 Thread Vlad Zahorodnii
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  = 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

2020-01-17 Thread Vlad Zahorodnii
On 1/17/20 12:46 AM, Kai Uwe Broulik wrote:
> It provides useful visual information.
> 
> auto foo = bar();
> auto baz = 

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

2020-01-17 Thread David Edmundson
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 = 
>

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

2020-01-16 Thread Friedrich W. H. Kossebau
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

2020-01-16 Thread David Jarvie
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  = 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

2020-01-16 Thread Kai Uwe Broulik




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 = 

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

2020-01-16 Thread 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.

> 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  = 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

2020-01-16 Thread Kai Uwe Broulik

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  = 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

2020-01-16 Thread Vlad Zahorodnii
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