On Mar 18, 2014, at 11:04 AM, Daniel Teske <[email protected]> wrote:
> On Tuesday 18 Mar 2014 09:44:17 Christian Kandeler wrote: >> On 03/05/2014 11:12 AM, Poenitz Andre wrote: >>> Ziller Eike wrote: >>>> One rule for using “auto” that I’d like to establish, is to use it only >>>> “when the type is obvious when reading the code”. Of course what that >>>> exactly means should be discussed and shown in some examples, and then >>>> it’s still up for interpretation. E.g.: >>>> >>>> Yes: >>>> >>>> auto f = new FooBar; >>>> auto a = new A; >>>> auto myAction = menu->addAction(…); >>>> auto it = list.const_iterator(); >>>> >>>> No: >>>> >>>> auto i = 4; // the difference between “4;” and “4.;” is subtile with big >>>> consequences> >>> What is obvious for some might unfortunately not be so obvious for others. >>> >>>> From the list of "Yes" cases I only fully agree with "auto it = >>>> list.const_iterator();">> >>> I'd actually like to restrict the use of auto to cases where it >>> "significantly" reduces typing and line noise (say, identifiers longer >>> than x chars, and to cases where it doesn't change meaning. >> >> On the other hand, patches that change types in function signatures will >> potentially get much smaller if "auto" is used extensively. For >> instance, if you take a look at the "QString -> Core::Id" or "QString -> >> Utils::FileName" patches, you will notice that quite a number of hunks >> would disappear entirely. > But that's NOT a good thing. After all the type changed, the behavior > changed, > and you need to look at all those places to consider the implications. > Utils::FIleName is a mostly drop in replacement for QString, but it behaves > differently. > >> In general, it seems to me that using "auto" is sensible when assigning >> the result of a function call, as the type is already specified. > > The ultimate aim of our coding style is to make code maintainable, by being > readable. > > If you need to lookup the return values of functions, to understand code then > that makes the code less readable to me. The types of variables are > important, > and thus shouldn't be hidden. I agree with Daniel. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
