[Development] RFC: more liberal 'auto' rules?

[Bubke Marco]

On December 4, 2015 21:33:57 André Pönitz <apoenitz at t-online.de> wrote:

> On Fri, Dec 04, 2015 at 08:01:59PM +0100, Olivier Goffart wrote:
>> > > You don't see any type.
>> > > 
>> > > This code that use auto is not less readable. Even if you don't know
>> > > what's the type of bar without looking it up.
>> > > 
>> > >   auto *bar = foo->bar();
>> > >   bar->setFaz(m_factory->createFaz(bar->type()));
>> > 
>> > Isn't this kind of a bad example, because there was no type declared/visible
>> > in the first place?
>> 
>> Precisely my point!   
>> There is no type visible before and nobody complains.  So why should one 
>> suddenly complains there are no types in the second snippet
>
> Because they are different from a human reader's point of view.
>
> In the second snippet the scope of the 'bar' is larger than for an immediate
> use. This loses the context in which it is used, i.e. makes it harder to
> reason about whether the use is ok, and adds load on a human reader that
> needs to keep mental track of this 'untyped' item when reading the code until
> it goes out of scope in case there's another use of this item.
>
> Both alternatives help to reduce that load:
>
> - immediate consumption of the temporary makes it explicit that the item is
>   used exactly once and provides the consumer as additional context, helping
>   judging whether the use is ok,
>
> - using a separate line with a real type provides a stepping stone by
>   giving additional information about the intermediate item *to the
>   human reader*, helping him to split the task of verifying that
>   'the right thing is produced and consumed' into smaller subtasks.

For subtask you should write a new function with a descriptive name. Actually I don't buy they argument that explicit types improve readability so much as we allow long functions which do many subtasks. In python a never missed the types and python code in general is in my opinion much more readable. In my opinion is the culture and not so much the style guides. 

I think readable code is produced by programmers who care and not so much by style guides. It is easy to write unreadable code which complies to a style guide but much harder to write good readable code. And if I look at our code I must say I have seen much more readable code. So we have plenty space to improve. ;-)

I think we discuss the matter of types so much because we have not a good culture to give variables and functions descriptive names. And how to decompose larger functions in smaller thanks to describe the intention. It's not only Qt but C++ in general.

My argument for auto is quite simple that it is makes dependency  breaking easier which is very important for Test Driven Development. And if you have good tests you can refactore your code much easier because you know the probability to introduce new bugs by code changes is much lower. This refactorings leads to much better readable code. So my argument is that should be used if it leads to more readable code. Our style guide can only gives hints about it.  So developing rigid rules which stop the code to envolve in a more readable state is maybe not that smart.

In the end you have always trust in the developers that they cares about the readability of what they produce. 

So I would like to add the advise to use auto if it makes unit testing easier.

And with the clang code model we could add refactorings which change auto to the actual type too. But I  prefer to visulize it in a other way. We could provide some kind of overlay.

>> > I really dislike hiding types behind a generic keyword.
>> 
>> Because the type is redundent
>
> It might be redundant for the compiler, but it is not for human
> readers of the code.
>
>> and it's one reason less to make errors:
>> Using 'int' instead of 'quint64' or 'size_t', or QString instead of QByteArray 
>> is way to frequent. (and the compiler won't complain)
>
> ["QString instead of QByteArray" does not happen with proper
> QT_NO__CAST_*_ASCII settings.  Not to mention the cases where mindless
> replacement of explicit types by 'auto' doesn't produce identical results.]
>
>> It is also refactoring-proof.  Because you might want to change the name of
>> the type from "FazManager" to "FazHolder", and then you need to touch less
>> code in your refactoring
>
> Code is typically read more often than changed. Targeting at making
> specific refactorings easier is optimizing the wrong utility function.
>
> Andre'
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone