[cfe-dev] [clang-tidy] Dealing with check names

[Aaron Ballman via cfe-dev]

On Mon, Dec 12, 2016 at 10:02 AM, Piotr Padlewski
<piotr.padlewski at gmail.com> wrote:
> Hi,
> as clang-tidy grows there are more and more checks. One of the problem I see
> is that "misc" check group is not user friendly - there are many checks that
> do so many different things that usually user don't want to enable whole
> group.
> Other groups like modernize, performance, google, cert, boost, llvm doesn't
> have this problem. Naturally the solution would be to split the group into
> smaller groups that would mean more.
> The problem is that we should not change names because old configs will not
> work.
>
> Do you have some ideas how we could fix it, so we could make it easier for
> users to use it?

I think that trying to reduce the craziness in the misc module is a
good goal, thank you for bringing this up!

The way we've solved this in the frontend is to not try to make the
groupings overly large, but instead base the groupings on something
tangible. For instance, we have -Wunused to enable a slew of unused
diagnostics of varying kinds, -Wdeprecated for various deprecated
diagnostics, etc. However, we're also fine having diagnostic "groups"
that contain only a single member because not all diagnostics are
easily categorized. Perhaps we could use a similar mechanism for
clang-tidy, instead of trying to come up with only large groupings?

Some checks are going to be very easy to group together, like coding
standards (cert, cppcoreguidelines, google, llvm). Other checks are
still pretty easy to group together because they relate to a shared
goal (readability, performance). But I think that a lot of checks are
essentially unrelated, and trying to force them into a categorization
will always be a losing battle.

> Other feature that we could add if we would know how to solve it is that we
> could make new groups that would mostly have aliases to other checks. This
> might be specially useful for cert checks - the cert code names doesn't tell
> anything, so it would be good to have these checks with proper name in
> different group so normal user could see what this check is doing from name
> and CERT users could run checks with cert group as it was before.

We already have this functionality, so I'm not certain what you are
proposing to add. Also, the CERT names do tell you information -- they
map to specific CERT coding guideline names, which have a unique,
stable identifier. They mean something to people trying to conform to
CERT's coding guidelines.

> One solution that I see is to reserve old name and make redirection, and
> maybe output warning about deprecated name when user would use special flag
> (e.g. verbose)
>
> What do you think about this problem?

I think that aliases to other checks are orthogonal to the problem of
grouping checks together. Certainly, I think that aliases are useful;
we already have checks that are shared between modules, such as checks
used by coding standards. However, I don't think that we will ever
have a satisfactory large-scale grouping for all of our checks without
a "misc" category, and that category is almost always going to be the
default for new checks (which is what we see in practice in the
frontend). I think we should not attempt to reinvent the wheel and
instead use the grouping concepts from the frontend, which would
likely do away with the misc- category entirely.

~Aaron