What rule do you wish FxCop/Gendarme had?

Question

What definable static code checking rule do you wish to see added to FxCop and/or Gendarme?

Why to do you wish to see the rule added, e.g what are the benefits etc?

How could your rule be implemented?

Eugene

FXCop does not perform static code checking, it checks the compiled assembly (IL). Static code analisys is done via StyleCop. – Gravettian

@BeowulfOF, I would say that FXCop did do static code checking, it just does not check the number of spaces you have on each side of a "=" etc. StyleCop does more style checking, e.g. id does not trace control flow between methods etc. – Eugene

Microsoft states that only assemblies are analysed by FXCop, not the source code. msdn.microsoft.com/en-us/library/bb429476%28VS.80%29.aspx – Gravettian

@BeowulfOF: It's still a static analysis though - it does not do any checking on running code. – Leonerd

Answer 1

Personally, I would prefer to see not using IDisposable implementations in using statements.

So if you had code like this:

var fs = new FileStream(...);

// Other code.

fs.Dispose();

It would tell you to use it in a using statement.

The benefit would be that it would alert you to cases you might not be aware of where objects that should be disposed are not being disposed in a timely manner.

However, there are enough times where it's a valid situation to NOT declare IDisposable implementations in a using statement for a rule like this to become a pain very quickly. Most often, this case is taking an IDisposable implementation as a parameter to a method.

What I do not mean is usages of classes where the implementation details remove the need for calling Dispose, (e.g. MemoryStream or DataContext); those implement IDisposable and should always have Dispose called on them, regardless of the implementation details, as it is always better to code against the contract exposed.

Methyl

@Ian Ringrose: Updated my response to clarify. – Methyl

VS2010 Code Analysis has a non-breaking rule for this: msdn.microsoft.com/en-us/library/ms182289%28VS.100%29.aspx – Lianna

Answer 2

I'd like to define and implement my own rules very quickly. I tried this once for FxCop, but I found the API not to be very clear - and there was not too much documentation around. I used FxCop 1.36, maybe things changed ...

So I'd like to see FxCop having a clear and easy to use interface ... that would be great :)

The rules I tried to implement were:

• DocumentInternalMethods
• DocumentInternalTypes
• ...

Basically I wanted to enforce xml-comments on non-public members.

Swarm

Use StyleCop for this, it has a rule for that builtin. XML-comments are not compiled to the assembly anyway, so the FXCop cannot see if those are defined or not, since it only analyses the compiled assemblies. – Gravettian

I know about StyleCop, but at this time I wanted to implement it in FxCop - and I did that. You are right, you have to load the xml-files separately. – Swarm

Answer 3

I'd really like the binary analysis to be smart enough to recognize the possibility of an interface.

If it could determine from approaching the defined types and their members, if there are commons that could be extrapolated into an interface.

Clearly, this should not be more than a warning, since it is sometimes whished to explicitly not use an interface.

Gravettian

Answer 4

Upon thinkin about this, I too would like to see the binary analysis to be smart enough to check possible downgrade of access modifiers.

It shouldn't be to hard to determine if a class, property or method could be more restricted.

Gravettian