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

Chris Lattner clattner at apple.com
Sat Mar 1 22:41:37 PST 2014


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:

> +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.

> +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)?

-Chris




More information about the llvm-commits mailing list