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

[Piotr Padlewski via cfe-dev]

2016-12-21 2:34 GMT+01:00 Alexander Kornienko <alexfh at google.com>:

>
> On Mon, Dec 12, 2016 at 4:02 PM, 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.
>>
>
>
> Most checks in "misc" could be better described as "checks targeting
> bug-prone patterns" and moved to a new module (e.g. "bugprone"). That would
> make things better.
>
On the other hand, more than half checks could be categorized to that. Even
some readability and modernize checks could be categorized this way because
they find code code that is bugprone and change it to something that is
less bugprone (either more modern or more readable). I think we need to go
deeper and find some more specific names.


>
>
>> The problem is that we should not change names because old configs will
>> not work.
>>
>
> Following this logic, we should not add new checks or add/remove/change
> check options, since some configs could stop working as they used to. Is
> there an evidence of this being a serious issue?
>
Good point.

>
>
>>
>> Do you have some ideas how we could fix it, so we could make it easier
>> for users to use it?
>>
>> 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.
>>
>
>>
>
>>
>> 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)
>>
>
> I personally don't think adding a deprecation mechanism for clang-tidy
> checks is valuable. We could instead implement some form of validation of
> check patterns (which could, for example, try to remove each part of the
> glob list and see whether the resulting set of enabled checks changes).
>
>
>>
>> What do you think about this problem?
>>
>> Piotr
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161223/92b5b990/attachment.html>