<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-12-21 2:34 GMT+01:00 Alexander Kornienko <span dir="ltr"><<a href="mailto:alexfh@google.com" target="_blank">alexfh@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Dec 12, 2016 at 4:02 PM, Piotr Padlewski <span dir="ltr"><<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div>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.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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. </div></div></blockquote><div><br></div><br class="m_-1499870281529799101gmail-Apple-interchange-newline"></span><div>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.</div></div></div></div></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The problem is that we should not change names because old configs will not work.</div></div></blockquote><div><br></div></span><div>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? </div></div></div></div></blockquote><div>Good point. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Do you have some ideas how we could fix it, so we could make it easier for users to use it?</div><div><br></div><div>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. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div><div>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)</div></div></blockquote><div><br></div></span><div>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).</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>What do you think about this problem?</div><span class="m_-1499870281529799101gmail-HOEnZb"><font color="#888888"><div><br></div><div>Piotr</div><div><br></div></font></span></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>