[cfe-dev] RFC: clang-tidy readability check to reduce clutter: unnecessary use of auto and ->

Larry Evans via cfe-dev cfe-dev at lists.llvm.org
Mon Nov 9 00:28:09 PST 2015


On 11/07/2015 03:40 AM, Fabio Fracassi via cfe-dev wrote:
> Hi,
>
> On 06/11/2015 19:08, Richard via cfe-dev wrote:
> [...]
>> N2541 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2541.htm>
>> introduced auto and the trailing return type syntax.
>>
>> Now people are using auto and -> on function signatures where the
>> return type is stated explicitly anyway.  This results in code like:
>>
>> auto main() -> int
>> {
>>   return 0;
>> }
> so?
>
>> Srsly?  Is this really improving anything over
>>
>> int main()
>> {
>>   return 0;
>> }
> no, but it is not worse either.
>
>> To me this is introducing unnecessary clutter
> it is more uniform, and for mathematically inclined people it is also
> more natural.
> just because it is a new syntax it doesn't  make it more cluttered or
> anything.
>
> Herb Sutter recommends this style in his Almost Always Auto article:
>
> *auto*f *(double ) -> int*; *auto*f *(dou ble)*{ /*...*/ }; *auto*f =
> [=]*(double)*{ /*...*/ };
>
> I actually like the style especially when declaring interfaces:
>
> struct X {
>     auto foo(int) -> bool;
>     auto bar(double, Y) -> Z;
>     ...
> };
>
> because it naturally aligns the most crucial information, the function
> name at the beginning of the line and mostly at the same column.
>

+1

People will read code more than they write it and finding
where a functions are declared is easier if their names are
in the same column.  After all, people are used to this when
looking in a dictionary where the names are always in the
far left column and declaration do form a sort of dictionary
of names.  Thats also why I prefer:

  using T = //some complicated type expression
    ;
rather than:

  typedef  //some complicated type expression using symbol T
           //where the name of the typedef name appears.
    ;

-regards,
Larry






More information about the cfe-dev mailing list