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?

Was it helpful?

Solution

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.

OTHER TIPS

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.

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.

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top