[PATCH] D30896: [Clang-tidy] add check misc-prefer-switch-for-enums

Alexander Kornienko via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu May 11 05:24:24 PDT 2017


alexfh requested changes to this revision.
alexfh added a comment.

In https://reviews.llvm.org/D30896#703046, @jbcoe wrote:

> I think that clang-tidy allows case-specific subsetting of C++. It is said that C++ contains a beautiful language and I've found that definition of beauty to be very use-case
>  specific. Checks for side-effect free, Haskell-like, functional code would be of enormous interest to some subsections of the C++ community ( financial asset pricing and risk)
>
>   but of very little interest to others (device drivers for embedded code). It would seem an enormous loss to me to require all clang-tidy checks to be generally useful. 


We don't require checks to be useful to every single C++ developer, but there is a certain bar the check should meet. It's not well defined, but I don't think we want checks that are only useful to a single person / company / code base (maybe with an exception of LLVM, since, well, clang-tidy is a part of it ;). The rationale is simple: every check added to clang-tidy adds up to all sorts of maintenance costs (source code maintenance, build and test times, binary sizes, complexity for the user, bugs filed, etc.), which should be outweighed by the usefulness of the check. When there's a single beneficiary of the check, they better care the costs of maintaining an out-of-tree check themselves.

Going back to what Aaron asked: is there any well-known coding standard, book or any other credible publication that formalizes recommendations on where using `switch` is preferred over `if`? I'm sure "enormous interest" would warrant existence of this kind of a recommendation, which might justify the presence of the check.

> It's a simple matter to define a clang-tidy config file to enable different checks in different parts of a code base.


Repository:
  rL LLVM

https://reviews.llvm.org/D30896





More information about the cfe-commits mailing list