[PATCH] Update the coding standards to provide some guidance for a few constructs in C++11

[Chandler Carruth]

On Sat, Mar 1, 2014 at 10:41 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Feb 28, 2014, at 6:44 PM, Chandler Carruth <chandlerc at gmail.com> wrote:
> > I talked to Richard Smith, Doug Gregor, and John McCall (as some of the
> more language oriented folks in the community), and with their help I came
> up with these additions to the coding standards. I'd like to get some
> broader input on these, but ideally I'd like to paint these bikesheds
> pretty quickly, put something in place, and revisit them if these
> guidelines don't really work out in practice.
> >
> > http://llvm-reviews.chandlerc.com/D2905
>
> Overall, lgtm, a couple of suggested additions:
>

Thanks! Submitted in r202620. If there are further tweaks, we can do them
in subsequent commits.


>
> > +Format Lambdas Like Blocks Of Code
> > +""""""""""""""""""""""""""""""""""
> > +
> > +When formatting a multi-line lambda, format it like a block of code,
> that's
> > +what it is. If there is only one multi-line lambda in a statement, and
> there
> > +are no expressions lexically after it in the statement, drop the indent
> to the
> > +standard two space indent for a block of code, as if it were an
> if-block opened
> > +by the preceding part of the statement:
>
> Related to lambdas, it is worth mentioning that any functions which take
> std::functions should do so as their last argument.  You don't want a
> lambda body to come before a bunch of other random arguments.
>
> This has been the standard apple API standard for "blocks" and has worked
> out really well.
>

Same here as well. I like it. I'll add this in a separate commit, and let
me know if you have any issues with the exact phrasing.


>
> > +Use ``auto`` Type Deduction to Make Code More Readable
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +Some are advocating a policy of "almost always ``auto``" in C++11,
> however LLVM
> > +uses a more moderate stance. Use ``auto`` if and only if it makes the
> code more
> > +readable or easier to maintain. Don't "almost always" use ``auto``, but
> do use
> > +``auto`` with initializers like ``cast<Foo>(...)`` or other places
> where the
> > +type is already obvious and clear.
>
> How about making the recommendation be based on whether the expected type
> is obvious from context (e.g. dyn_cast/cast), or where the explicitly
> written type would have been abstracted anyway (std::vector<T>::iterator)?
>

Done (prior to submitting).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140302/2019b8ec/attachment.html>