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

Richard via cfe-dev cfe-dev at lists.llvm.org
Fri Nov 6 13:34:14 PST 2015


[Please reply *only* to the list and do not include my email directly
in the To: or Cc: of your reply; otherwise I will not see your reply.
Thanks.]

In article <CAFdkBy5EvyngcLBraxjd1Qq+XQAsy_QWPzdinsMfTj_ODG6eVw at mail.gmail.com>,
    Tim Halloran via cfe-dev <cfe-dev at lists.llvm.org> writes:

> While this seems like a good idea, perhaps the tidy it should examine the
> complexity of the type being "auto"ed. The new return value syntax seems
> good to move a long type to the end of a function declaration to help code
> clarity, even if it is not strictly necessary.
> 
> auto f() -> my_super_duper<long,long,long,long,long> {
>   ...
> }
> 
> A simple type name (e.g., int or Airplane) seems okay to do the proposed
> refactoring, beyond that seems less of a clarity win to me.

If I understand you correctly, you're saying that really long
complicated types hinder readability.

I agree.

I don't see how moving the really long difficult to understand type
name from the front to the end increases readability.  The source of
the difficulty in readability is the long type name, not its
placement.  The traditional solution to this problem of legibility is
to use a typedef:

typedef my_super_duper<long,long,long,long,long> super_duper_t;

super_duper_t f() {
...
}

Not only is f's declaration and definition going to need this
difficult to understand templated type instantiation, but it is likely
that f's callers may also need it.  If my function g returns the result
of f, then I also need this ugly type.

An alternative solution to a typedef is to wrap the type in an
intention revealing name that expresses the concept more directly.
For instance, it is very common to use a Point class to directly
represent 2D points, even though we could have used std::pair<float,float>.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
     The Computer Graphics Museum <http://ComputerGraphicsMuseum.org>
         The Terminals Wiki <http://terminals.classiccmp.org>
  Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>



More information about the cfe-dev mailing list