[Monodevelop-devel] [gendarme] Re: MD Gendarme Addin

[Sebastien Pouliot]

Hello Luciano,

If you're not already I suggest you subscribe to
gendarme at googlegroups.com

On Wed, 2008-11-26 at 18:17 -0500, Michael Hutchinson wrote:
> On Wed, Nov 26, 2008 at 4:02 PM, Luciano _ <lnc19 at hotmail.com> wrote:
> > HI All:
> >  I was talking to Michael and i will try to start the MonoDevelop Gendarme
> > addin.
> >  I have some affirmations/questions, Based on Michael post [*], that i need
> > to clarify, any help will be helpfull.
> >
> > 1) I use Gendarme with System.Diagnostic.Process to not depend on it.
> 
> Yup, it'll need to run gendarme to produce an xml file in the output
> directory, then read in the XML. The Smokey code analysis addin
> already does this, so that code might be a good starting point.

Basically you can have:
* one input XML file (optional, but it's how to configure everything);
* a few parameters, like the assemblies being analyzed;
* an ignore-list file (optional, but so useful); and
* one output XML file.

> This is the main priority IMO.
> 
> > 2) I have to make a widget/dialog to setup 

Before setting up you'll need to know what to setup. This means you must
be able to discover what is available (rules as a minimum, potentially
configurable options later) to present them to the user. 

Today different runners have different strategy. E.g. the console runner
base itself on a file (the rules.xml file shipped w/Gendarme) while the
wizard GUI runner inspects the rules assemblies to find the rules
available. The addin needs is kind of in-between. In any case there's no
need to link with the Gendarme binaries to get the information.

The other important feature IMO is to handle the "ignore-list", i.e.
stuff you don't want to be warned about the next time you ask for your
code to be analyzed. There should be a way to add to this list and a way
to remove ignored stuff from it.

> Rules.xml file with all the
> > futures: Rules sets, ignore rules, Severity levels, etc.

Using an XML file you can*

(a) specify which rules are used (or not) during analysis;

(b) define different rule sets (inside the same XML file);

(c) set options on rules [1];

(d) set the applicability of each rule on:
	everything (the default on the console runner);
	code visible outside the assembly;
	code only visible inside the assembly;

        * but you don't need to support all possible options in order to
        have a useful addin ;-)

What you cannot set in the XML file are filters on Severity and
Confidence (i.e. filters on the defects) but you can specify them on the
command-line (since Gendarme 2.2). 

However it may be easier to filter defects later, i.e. not at analysis
time, when you load the XML results (and that would work on Gendarme 2.0
too). This would let users change filtering without re-analyzing the
solution (or projects) which would be faster (since you would need to
reload the results anyway).

> See #4.
> 
> > 3) User must jump to the offending code line/file and an explanation of the
> > fault: This is the hard part, i will try to save log file, an parse it, any
> > other way? (Parse html could be another way, but i think is harder than log
> > file). I didn't see the log file, i didn't know if my approach is correct.
> 
> There's the XML file, which should be very easy to load. The smokey
> addin does this.

You can use "--xml results.xml" to get the defects inside an XML file.
The text and HTML formats would not only be harder to parse but also
more likely to change too in future releases.

> > 4) I will use One rules.xml file per solution/target (Solution &
> > Debug/Release/Test/etc)
> 
> I'm not sure how rule sets should apply to
> project/solutions/configurations, but this seems like a good model:
> http://blogs.msdn.com/fxcop/archive/2008/11/12/fun-with-code-analysis-rulesets.aspx

In VS.NET people generally defines a target for code analysis - i.e.
where CODE_ANALYSIS is defined (you can see it inside the above link).
This lets attributes, like [SuppressMessage], be compiled into the
assemblies [2]. In the future it's likely people will want contracts to
be part of the analysis (since it gives more clues about the code and
rules are always hungry for clues).

I think people expects to be able to run analysis on both the solution
and on specific projects. It's important to note that running the
analysis on each projects will be a bit different (result wise) than
running it on the solution. This is because some rules works on the set
of assemblies being analyzed (so more assemblies, more complete the
analysis can be and more potential defects can be found). IMO both
options are valid (even if the solution-level analysis is more
complete).

> > 5) Allow to check the rules before checking to VCS.

That's (quite) an advanced option - but something that you should keep
in mind.

> > 6) Use the MD Code DOM to find things not listed in MDB files. What is this?
> 
> Some analyses might report an error in a member, without having a
> location. MD has an internal type database with lots of line/col/file
> information so this could be a good fallback. Very low priority
> anyway, so don't worry about it :)

Yes, MDB has some limitations (e.g. fields, attributes) where no line
information is available. Having a fallback, eventually, would be a nice
addition.

> > 7) Add the Gendarme configuration file to the project.
> > 8) Warning message of gendarme result could it be shown in Construction Pad,
> > as "Wanings".
> 
> It's debatable exactly how gendarme severity should map to
> error/warnings in the errors pad.

It's unlikely that people will want all of them mixed with compiler
errors and warnings. You would be best to start with a separate view
where filtering and sorting is possible.

Later you might want to give the options, for each rule, to act as an
error, a warning or simply be shown in the code analysis view. That
could be a great place to ask if some defects are "commit
breakers" (point #5).

Don't hesitate to ask any questions (by email or on IRC).
Sebastien


[1] Right now the console runner use reflection to set options. Future
versionS of Gendarme (planned for 2.4) will start using System.Component
attributes to advertise rules options in a way that makes it easy to
build an UI on top of it.

[2] The [SuppressMessage] attribute is not supported in current version
of Gendarme - but the infrastructure is already in place (i.e. matching
Gendarme and FxCop rules) to make this possible in the future.