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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to