Specify severity for each set of rules

[Daniel Lidström]

Hello!

I'm having a situation where I would benefit if it were possible to
specify severity for each set of rules. For example, my rules are
currently:

<ruleset name="reporting">
<rules include="*" from="Gendarme.Rules.Correctness.dll" />
</ruleset>

I am running gendarme.exe with default severity (medium+). This is
reporting some CheckParametersNullityInVisibleMethodsRule that I do
not care about. Running gendarme.exe with severity high is more
appropriate regarding CheckParametersNullityInVisibleMethodsRule,
however I'd like the other correctness rules to still use medium+. If
I could specify this in my rules.xml I think this would be nice:

<ruleset name="reporting">
<rules include="*"
exclude="CheckParametersNullityInVisibleMethodsRule"
from="Gendarme.Rules.Correctness.dll" severity="medium+" />
<rules include="CheckParametersNullityInVisibleMethodsRule"
from="Gendarme.Rules.Correctness.dll" severity="high" />
</ruleset>

Regards,
Daniel

[Sebastien Pouliot]

You can fill a bug report (enhancement) for this (you can copy-paste this email into the bug's summary).

This is a bit complex to add (at least efficiently) and remove some optimization possibilities. E.g. right now excluding a rule means it's not executed (saving time and memory).

It's also something that would likely evolve into several similar requests (e.g. confidence, number of defects, *and* or *or* operators...). At some point the decision code (per defect) would get larger than most of the rules - and a lot of the cost would be seen/felt by every users.

Now I see how this could be useful ;-) and I've already suggested a few times (in emails or on IRC) to do some post-processing (e.g. xslt, or c# xlinq) of the results (.xml) then, if needed, re-apply the (gendarme-provided) xslt to get back the HTML output. Bake this into a script and it's as easy to work with than Gendarme (at least the console runner) is.

The other option would be to support "user filters", e.g. an assembly, dynamically loaded, that would implement a (new) Gendarme interface that will allow it to accept/reject any defect being found. The impact on the runners would be minimal (great for anyone not needing such feature) and the flexibility/performance would be as great as the supplied filter.

Sebastien

[Daniel Lidström]

On 4 mar, 14:38, Sebastien Pouliot <sebastien.poul...@gmail.com>
wrote:
> Le 2011-03-04 à 05:41, "Daniel Lidström" <dlidst...@gmail.com> a écrit :
[...]

> > If I could specify this in my rules.xml I think this would be nice:
> >
> >    <ruleset name="reporting">
> >        <rules include="*"
> > exclude="CheckParametersNullityInVisibleMethodsRule"
> > from="Gendarme.Rules.Correctness.dll" severity="medium+" />
> >        <rules include="CheckParametersNullityInVisibleMethodsRule"
> > from="Gendarme.Rules.Correctness.dll" severity="high" />
> >    </ruleset>
>
> You can fill a bug report (enhancement) for this (you can copy-paste this
> email into the bug's summary).

Yes, it's been done.

> This is a bit complex to add (at least efficiently) and remove some
> optimization possibilities. E.g. right now excluding a rule means it's not
> executed (saving time and memory).
>
> It's also something that would likely evolve into several similar requests
> (e.g. confidence, number of defects, *and* or *or* operators...). At some
> point the decision code (per defect) would get larger than most of the rules
> - and a lot of the cost would be seen/felt by every users.

I did not think of that. For what it's worth though, for me
personally, having the
option to set a --limit for each set of rules is not something I can
imagine I would ever like to do.
For me there are other ways of keeping the issues to a low.

> Now I see how this could be useful ;-) and I've already suggested a few
> times (in emails or on IRC) to do some post-processing (e.g. xslt, or c#
> xlinq) of the results (.xml) then, if needed, re-apply the
> (gendarme-provided) xslt to get back the HTML output. Bake this into a
> script and it's as easy to work with than Gendarme (at least the console
> runner) is.

I guess this is how I will solve it now. I already have a ruby script
that processes the xml.
For the moment I am only reporting high priority defects, but I do
have the option of adapting
my script to do post processing for my specific needs. It is a good
suggestion.

> The other option would be to support "user filters", e.g. an assembly,
> dynamically loaded, that would implement a (new) Gendarme interface that
> will allow it to accept/reject any defect being found. The impact on the
> runners would be minimal (great for anyone not needing such feature) and the
> flexibility/performance would be as great as the supplied filter.

This would require compilation to change, not simply configuration. Or
it
requires an additional configuration file in addition to the rules.xml
one.

Thanks!

Regards,
Daniel