Hello.
And welcome to C++ Weekly.
I'm your host, Jason Turner.
I'm available for code reviews, contracting,
and on site training.
Now this episode is one that, in some ways,
I'd prefer to not make.
But I have in the past, and you can check out my other videos
on Clang-Tidy and learning modern C++,
strongly suggested that you go in and use Clang-Tidy and turn
on all of the warnings.
Because you may as well learn from Clang-tidy.
Now I think I'm going to have to change that advice now.
So this episode is Clang-Tidy warnings to disable.
And we might have to get to a point
where I'm only suggesting specific things to enable.
And the problem from my perspective,
my perspective as someone who produces these videos
and does training, is if I tell you
to enable all of the warnings, then
I expect with most static analyzers
that all of the warnings are something that are very useful.
But Clang-Tidy is now getting a lot
of very specific Google project warnings enabled in there.
And I don't know how all of this comes together,
like how specifically checks get into Clang-Tidy,
and who vets them, and who allows whatever in.
But what we have here, and this is
the list of all of the Clang-Tidy checks that
are available in Clang-Tidy 8.
And I am recording this in December of 2018.
I know this changes often.
But what we can immediately see is
we have Abseil specific checks.
And Abseil is a Google project.
And then things that make sense, Android, OK, fine.
If there's a best practice for use with Android, do those.
And then bug prone checks, that's great.
If there is something that is bug prone,
we should probably avoid doing it.
And scrolling down, we've got certs.
Now certs are awesome, because these are known vulnerabilities
with specific things in the language.
So we should probably be following those certs,
so that we're not writing code that
has more security problems.
And then C++ core guidelines.
These are well vetted across the community, almost all of them.
And then we have Fuchsia.
Now Fuchsia is also a Google project.
And we've got a set of very specific Fuchsia warning.
And then we've got the Google warnings.
These are the ones that are specific
again to Google projects.
And this is the Google C++ rules.
Although, this does not by far check for all of them.
And then high CPP, these are high performance things.
And they tell you about interesting things,
like conversions that you're not aware of,
and perhaps if you're misusing push fact
verses in place and whatever.
So I do recommend most of the high CPP ones.
Although, you might occasionally have to disable one or two.
And then LLVM.
Those are specific to the LLVM project.
Misc, you know, up to you.
Modernize, modernize are almost always great.
There's a few that can get you in trouble.
But for the most part, they can take our old style code
and update them.
We like the modernize checks.
I always recommend to use them.
I don't know anything about Objective C.
Then we've got performance, readability.
You can disagree with some of the readability ones.
But now the parts that I wanted to call out specifically
are the ones that are specific to projects
that you're not working on right now.
You are probably, if you were watching this video, not
an Abseil developer.
Now some of those might be great,
but they also might be highly specific to that project.
And again, if you're watching this video right now,
you are probably not a Fuchsia developer,
and you are probably not a programmer at Google.
So the rest of them, be sure to use them freely.
But I'll call out a couple of things
that I find particularly problematic, if I may,
getting back to the Fuchsia ones.
Fuchsia does not allow trailing return types,
and it says, except for those using decal type specifiers.
Now I don't necessarily use trailing return types
everywhere, but there is a good reason
to use them in many cases.
And of course, an exception must be made for lambdas,
because they have to be used in lambdas.
So if you're looking for consistency in your code base,
then it might be good to use trailing return types.
So that's just outlawing them altogether.
The operator overloading is completely disallowed
in Fuchsia unless it is a assignment operator, which I,
again, I find this not conducive to writing good clean C++.
I know the arguments against operator overloading.
However, we, as a community, have fully
agreed that if we've got some type,
take for example this right here with this operator plus,
some type like a numeric type or something or a matrix
where operator plus has a well-defined meaning
and we wanted to be able to add two operators together,
we're not Java programmers.
We don't do add matrix one comma matrix two.
We do matrix one plus matrix two.
So there's that.
And then the next one that I find particularly troubling
is the multiple inheritance unless they are
all pure virtual based classes.
This effectively makes using CRTP impossible.
And that's the curiously recurring template pattern.
You can look that up if you don't know what it is.
Now I'm exaggerating by saying it makes CRTP impossible.
But it makes other more interesting use cases
for this kind of thing much more difficult than they need to be.
So that's all.
That's my, I hope not terrible, short rant here
to just say keep using Clang-Tidy.
It's awesome.
It's great.
And I recommend almost all of them.
But you probably want to start disabling
the checks that are to specific projects
that you are not currently a developer on.
So thanks for listening to this episode.
There wasn't a whole lot to actually see programming
wise here.
But I hope you liked it.
And yes, be sure to subscribe to the channel,
maybe follow me on Twitter.