RS support for removing FxCop warnings

I can;t find any tool that automatically removes FxCop related "SuppressMessage" attributes when they are no longer needed. I think it would be a nice feature (post 4.0 probably) if RS did this, both via a "Remove all SuppressMessage" command, and via flagging unneeded SuppressMessage attributes as RS evolves to detect individual cases of removable occurrences.

8 comments
Comment actions Permalink

I usually handle this by inlining the FxCop attributes to make them more
discoverable when later refactoring the code base. One aspect of FxCop I do
not like is that it has a huge tendency to throw suppression attributes into
the global suppressions file for no good reason. It would be nicer if FxCop
itself built a collection of suppression attributes found in the code and
present those attributes that are no longer applicable (meaning those
attributes that did not actually trigger a suppression) in a dialog
somewhere with an easy way to remove them. I just don't see an easy way for
ReSharper to do this unless it implements its own duplicate FxCop
functionality.

"Brian Strelioff" <BKStrelioff@Hotmail.com> wrote in message
news:20850963.12051211403611397.JavaMail.jive@app4.labs.intellij.net...

I can;t find any tool that automatically removes FxCop related
"SuppressMessage" attributes when they are no longer needed. I think it
would be a nice feature (post 4.0 probably) if RS did this, both via a
"Remove all SuppressMessage" command, and via flagging unneeded
SuppressMessage attributes as RS evolves to detect individual cases of
removable occurrences.


0
Comment actions Permalink

I agree there is no "easy" way to do it, and there is some risk in tying RS to FxCop rules. But I think the market for RS would be broadened if it supported an automatic way to fix FxCop violations (in addition to removing obsolete SuppressMessage occurrences). This is really the next generation of "code cleanup", and some products are already available that begin to address these kinds of issues by automatically refactoring/fiing the code rather than just generating warning/error messages or Suppress... For one example, see http://submain.com/codeit.right/ .

0
Comment actions Permalink


"Brian Strelioff" <BKStrelioff@Hotmail.com> wrote in message
news:24429262.22221211658761383.JavaMail.jive@app4.labs.intellij.net...
>I agree there is no "easy" way to do it, and there is some risk in tying RS
>to FxCop rules. But I think the market for RS would be broadened if it
>supported an automatic way to fix FxCop violations (in addition to removing
>obsolete SuppressMessage occurrences). This is really the next generation
>of "code cleanup", and some products are already available that begin to
>address these kinds of issues by automatically refactoring/fiing the code
>rather than just generating warning/error messages or Suppress... For one
>example, see http://submain.com/codeit.right/ .

You could then go one futher; and start supporting StyleCop now it's
released. The StyleCop rule settings are XML based; and by default they
class with Resharper (for example put using statements within the namespace;
the order of access modifiers, removal of {} around single line statements
and so on.) Syncing the resharper recommendations to the stylecop settings
would be a blessing.

0
Comment actions Permalink

Hello,

You could then go one futher; and start supporting StyleCop now it's
released. The StyleCop rule settings are XML based; and by default
they class with Resharper (for example put using statements within the
namespace; the order of access modifiers, removal of {} around single
line statements and so on.) Syncing the resharper recommendations to
the stylecop settings would be a blessing.


You can write the sync tool if you'd like, as R# settings are XML too. But,
regarding that the only field both R# and StyleCop have a good support for
is code formatting, and that StyleCop in its present state is quite a silly
and useless tool in this domain, I'd rather consider it a waste of time.

I don't think any reasonable person is interested in learning that a curly
brace is positioned incorrectly in some code file. It's either that he does
not care, or would like the issue to be corrected automatically. R# is good
enough at doing the latter — you can run Code Cleanup (with much more complex
things handled than mere spacing, as of R#4) on the Solution element in the
Solution Explorer, and each of your files will be treated automatically.
This looks like a more realistic scenario for treating the code formatting
issues than clicking through the report. We don't even have to bother developers
with warnings for such simple matters as spacing.

Basically, I can see three categories of StyleCop rules:

  • Code formatting, like "this" prefixes, access modifiers, bracket usage

and placement, member order, and using directives disposition. Automatically
treated by R#. I think we could possibly include a standalone utility (like,
MSBuild task for running it automatically) for reformatting a solution or
a project, if there are enough user requests for such functionality.

  • Naming conventions. Duplicated by FxCop, not quite treated by R# right

now, I must admit. There are plans to address the naming subsystem in the
next version, to provide more flexibility in its settings and add code warnings
on naming style violations. Automatic fixes are impossible, as in most cases
they involve non-trivial refactorings with possible conflicts and breaking
changes to public API.

  • XmlDoc comments. R# has limited support for them. There are plans to treat

their XML first-class to enable XML features on it and, with that, more coding
assistance and analyses, but the timeframe is not yet set. Again, not much
settings to sync with.


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

I too was disappointed by StyleCop, and agree that the RS approach of fixing, rather than just warning about, stylistic issues is far better.

I am not a fan of MSBuild-time modifications to source in this day and age. I think tight integration with VS2008 is far better, and with the support in TFS for checkin policies (such as all dependant projects have been cleanly built after any modifications, application of specific FxCop rules, ...) I think we should avoid "hidden/background" changing of source code.

Also I think RS support for per-project option configurations should be a higher priority than any standalone utility.

0
Comment actions Permalink

Hello,

I think tight integration with VS2008 is far better, and with the
support in TFS for checkin policies (such as all dependant projects
have been cleanly built after any modifications, application of
specific FxCop rules, ...)


Thank you for your suggestion. We'll consider TFS policies when planning
for future versions.

I think we should avoid "hidden/background" changing of source code.


Yes, I were rather considering a tool you can run from time to time.

Also I think RS support for per-project option configurations should
be a higher priority than any standalone utility.


Do you mean per-project or per-solution?


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0
Comment actions Permalink

I did mean "per-project", as overrides of "per-solution" default settings. Supporting per-project settings would allow different values for projects that contain generated (Designer, Reference.cs, Dataset ...) files, which typically generate orders of magnitude more violations than hand-maintained code.

There are conflicting goals: using generated files "as is", which leads to thousands of violations, versus a clean compilation, which may require refactoring generated code to conform to the specific style/naming/... settings.

0
Comment actions Permalink

Hello,

I did mean "per-project", as overrides of "per-solution" default
settings. Supporting per-project settings would allow different values
for projects that contain generated (Designer, Reference.cs, Dataset
...) files, which typically generate orders of magnitude more
violations than hand-maintained code.


I'm sure the settings framework will allow the trick as soon as we get our
hands on it in the next version, but I doubt that it will have its way into
the Options UI. Adding one more level will make it way too complex; however,
let's wait for some prototype.

As for the generated code, all you have to do is surround it with some #region
and mention its name on the R# -> Options -> CodeInspection -> Settings page.
This will effectively conceal it from most of R#'s analyses. Another solution
is to parent the generated files under some other .cs file, with the "DependentUpon"
metadata item in the project file (see how .designer.cs is mounted into its
parent).


Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”


0

Please sign in to leave a comment.