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

[Bubke Marco]

On December 3, 2015 19:06:17 Thiago Macieira <thiago.macieira at intel.com> wrote:

> On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
>> The remainder of the C++ world is moving towards an "always auto" scheme. We
>> don't need to go there, but I'd at least like to propose, for new code and
>> as a drive-by, the *required* use of auto for:
>
> The remainder of the C++ world is no indication for us.

Actually I think it is. If Qt is to different we loosing mind share. 

> Also remember that, for us, the source code is a product. We need to have 
> readable source code, so we have two ground rules that must be respected:
>
>  1) the use of auto must make the code more readable, not less
>  2) Qt Creator must be able to parse and deduce the correct type

They Clang code model is doing it already and we working hard on building up a infrastructure on țop of clang to exchange the old code model with the new clang version completely. 

> #2 is, of course, a transient issue, because Creator will get better over 
> time.
>
> As for #1, it's subjective. "More readable" does not mean "fewer characters". 
> If someone reading the code cannot understand what that variable is doing, 
> then it's less readable. Thankfully, Qt API is well designed so you can 
> usually tell from the function name what it does, without having to know the 
> class it is defined in. But it follows that if you're interfacing with non-Qt 
> API, then their API may be worse and this less readable. For example, the "is" 
> prefix for boolean properties helps a lot, since you won't have to decide 
> whether a plain word in English is a state or a an action, as in "empty".
>
>> - template code (esp., but not necessarily only, when the type name would
>>   require the use of 'typename')
>
> Agreed, except when in violation of the ground rules.
>
>> - all loop variables (both index and iterators)
>
> Except for primitives, because "int" is shorter than "auto".
>
>>   the reason being that spelling out the name is usually wrong:
>>   size_t i = stdVector.size() // wrong, should be std::vector::size_type...
>>   also helps when porting from Qt containers to STL ones
>
> I disagree. We'll use int, thank you. You know I disagree about porting from 
> Qt containers to Standard Library ones. Therefore, that is not an argument to 
> convince me to write uglier code with auto.
>
>> - all references to elements in a collection (same problem - way too easy to
>> misspell std::pair<int, int> for std::pair<const int, int>...)
>
> Example?
>
>> Optional use of auto: whereever it makes sense. Use your own judgement, but
>> remember: fear is a bad advisor.
>> 
>> For range-for, I'd suggest the following patterns:
>> 
>> - loop variable: singular name of collection name (foo : foos)
>>   - otherwise: 'e' (for element) or first letter (r : rects)
>> - for (auto e : collection) // (for pass-by-value types, or if you modify)
>> - for (const auto &e : collection) // for pass-by-reference types
>> - for (auto &e : collection) // mutating (also: pointer variables/no auto
>> *&e) 
>
> Agreed.
>
>> - for (const auto *e : collection) // const pointers
>> - for (auto *e : collection) // non-const pointer
>
> Why? Why not allow "auto e" and e is a pointer?
>
>> - explicit type name should be the exception
>
> Agreed.
>
>> This is covering a large part of the usefulness of auto.
>> 
>> I don't really like to add anything more detailed to the "rules". Scott
>> Meyers' books do a much better job at explaining than we ever could.
>
> Qt has never and will never build without warnings from -Weffc++. Some of 
> Scott's rules are good, but we do not have to adopt them all.
>
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Sent from cellphone