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

[Matthias Gehre via cfe-dev]

Fabio Fracassi via cfe-dev <cfe-dev at lists.llvm.org> schrieb am So., 8. Nov.
2015 11:58:

>
> On 07/11/2015 18:18, Richard via cfe-dev wrote:
> > [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.]
> I thought I did, I explicitly deleted your address from the to field, ...
> > In article <563DC703.4000507 at gmx.net>,
> >      Fabio Fracassi via cfe-dev <cfe-dev at lists.llvm.org> writes:
> >
> >> 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,
> > It *is* more clutter in the sense that it introduces unnecessary tokens.
>  From this perspective you are right in calling it clutter.
>
> > [...]
> > design principle) return void.  Writing 'auto f() -> void;' obscures
> > that this is a command until I get to the end of the declaration.  In
> > fact writing 'auto' puts me immediately in the mindset of "this
> > function is going to return a value" only to make me change my mind
> > when I reach the end and learn "oh, the value is void."
> Actually for exactly this reason I make an "exception" when using void,
> because void is special.
> And since void, like auto has exactly four characters it still fits
> nicely into the uniformity:
>
> auto f(int) -> bool;      // reads: I have a retun value ... and it is bool
> auto f() { return ...; }   // reads: I have a return value ... and it is
> whatever I return
> void g();                        // reads: I have no return value
>
> >> and for mathematically inclined people it is also
> >> more natural.
> > I didn't know you were appointed spokesman for all mathematically
> > inclined people?
> Sorry, this was not my intention. IMO the "naturalness" is there because
> the mathematical notation of a function is
> f: param1_t, param2_t -> return_t
> which is closer to
> auto f(param1_t, param2_t) -> return_t
> >> just because it is a new syntax it doesn't  make it more cluttered or
> >> anything.
> > To me, clutter is adding extra stuff in that's not necessary like
> > (void) argument lists or gratuitous use of auto.
> To me clutter is something that hinders readability without adding
> information.
> I think this extra tokens help rather than hinder readability (even if
> it does not add information), so I objected to the negative connotation
> of "clutter"
> >> Herb Sutter recommends this style in his Almost Always Auto article:
> > I assume you are talking about this:
> > <
> http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
> >
> >
> > That article is from 2013 and in subsequent talks on YouTube I've
> > seen people comment that "whacking everything with an auto hammer"
> > doesn't yield the benefits that were claimed at the time.  Furthermore,
> > just because Herb Sutter likes a certain style doesn't mean that I do.
> Sure, I just wanted to show that there are well reasoned people out
> there that think differently about this topic.
>
> This is ultimately a stylistic issue, and thus a matter of taste, which
> is hard to discuss. There are (more or less good) reasons to use both
> styles, and you can find (more or less good) reasons against each.
>
> > With clang-tidy we're not talking about the compiler creating a warning
> > or error because you use a certain code construct.  clang-tidy is
> > like clang-format.  You don't like LLVM code formatting conventions?
> > Nothing's forcing you to use them.
>
> I  wasn't aware that clang-tidy and clang-format were there to
> (exclusively) force llvms style, I was under the impression that they
> were general tools to clean up code bases to their individual styles.


Just as a side note, clang-tidy supports many checks that are not
applicable to llvm, e.g. in the cert, google and cppcoreguideline groups.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151108/849afd43/attachment.html>