Subject: Re: [boost] usage of auto in tutorials
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2019-03-19 18:07:16
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrzej Krzemienski via Boost
> Sent: 19 March 2019 15:49
> To: boost_at_[hidden]
> Cc: Andrzej Krzemienski
> Subject: Re: [boost] usage of auto in tutorials
> wt., 19 mar 2019 o 16:37 mike via Boost <boost_at_[hidden]> napisaÅ(a):
> > > -----Original Message-----
> > > From: Boost <boost-bounces_at_[hidden]> On Behalf Of Stephan Menzel
> > via Boost
> > My personal rule of thumb for tutorial and demos is similar to how
> > you handle abbreviations in written text:
> > First time you e.g. use a function, you explicitly show what the
> > function returns. Afterwards I use auto where it makes sense
> > (And yes, I know there are conflicting opinions about
> > "where it makes sense").
> > With respect to the specific examples:
> > - Trailing return types in function declarations:
> > If the style guide doesn't say something different, I only use
> > them for very long type names and when they are needed.
> > None of this applies here, so I don't see the benefit,
> > but also not any harm. I'd say it is personal/project preference.
> > - The auto inside the if:
> > The return type of the function is shown just two lines above.
> > Again, personal opinion, but I'd claim it even increases
> > readability, because it is less visual noise.
> I wonder what others in this group think? Maybe we could come up with some
> guidelines for documentation writers.
I think that auto should be used sparingly in examples whose purpose is tutorial.
Examples of where one *must use auto* are the exception rather than the rule, and usually worthy of special note.
The main benefit of auto is 'syntactic sugar' for the writer, not the reader.
Spelling out the type is usually an important part of illustrating the example.
My 2p FWIW.
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk