Ability to exclude certain objects (Procedures/Functions/Files...etc.) from being processed for a rule
Currently there is no way to tell Code Analysis to ignore this specific object for a specific rule which has led to several false positives and wasted time re-investigating how to address the issue in the object only to come to the same conclusion as before that this is one of the rare cases where breaking that rule is ok.
My example is we have one stored procedure out of a thousand where the use of a NVARCHAR(2) makes sense and is actually more efficient then switching to a NCHAR(2) for what the code needs to do. Unfortunately the procedure is always flagged for violating BP009 - Avoid var types of length 1 or 2. And so every time a junior dev goes to work on the procedure they spend hours trying to remove the NVARCHAR(2) and replace it with a NCHAR(2) only to find out after a review with a senior that they wasted their time as this is the one case where it's ok.
What I would like to see is on each rule be able to specify the name of a object that should be excluded for that rule.
I know that this feature used to exist at one point for some of the rules because looking at the Code Analysis xml shows possible entries for it, but there's no graphical way to do it anymore and no documentation on how to set those items up in the xml.
-
Mike Hofer commented
I have the same experience as Richard Wells.
However, using inline comments, while useful in some scenarios, can clutter the code quite a bit. What might be useful is a way to place a "pragma" of some kind at the top of a stored procedure or function and have it apply automatically to the entirety of the code (or until the next GO statement).
I'm not sure how feasible that is, but it would be nice and reduce code clutter.
-
Richard Wells commented
I've just started using Code Analysis systematically and also find, similar to what I'm used to in working with compiler warnings, that I'd like a pragma to disable a flagging of a specific Issue within a limited scope.
For example, issue PE019 (Consider using EXISTS instead of IN) doesn't apply in a situations where I know the maximum size of the subquery result is tiny. (Probably why the message says "Consider ...".) I'd like to mute this Issue, perhaps like this, building on the similar control for formatting:
...
AND t.someothercondition = 1
-- sql prompt code analysis off PE019
AND t.item IN ( SELECT SplitVal FROM fnSplit(',', @items) )
-- sql prompt code analysis on PE019
AND ...