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

[Fabio Fracassi via cfe-dev]

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.
I didn't want to make any comment to what style llvm should use, just 
that I would hope that clang-tidy would support (or at least be open to 
support if someone bothers to write a patch) both, so that it is more 
generally useful.

Sorry for the noise,
I do appreciate the great work you guys are doing on clang and the nice 
clang tools.

Best
Fabio




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus