FXCop - How seriously do you take it?

Question

4.58/5 (5 votes)

See more:

I've been profiling my apps with FXCop, it seems to do an okay job of catching stuff, however, I completely disagree with it's suggestions in some cases. (This is more of an issue with the standards, and rules that drive the app, than the app itself.)

For example:

Quote:
Info : "Public constructors for abstract types do not make
sense because you cannot create instances of abstract
types."

I disagree.

http://msdn.microsoft.com/library/ms182126%28VS.100%29.aspx[^]

If you follow the link they gave me, it goes on to blah, blah, about how the type is "improperly" designed, etc,.

If you create an abstract class, and use virtual methods, you can do a lot of work behind the scenes in the base(abstract) class, keeping the class that inherits from it much cleaner. (This code must exist, either in the base class, or in the actual class, it's logical to me, to abstract anything you can, for simplicities sake. (And my sanity.))

So, on the occasion, when I need to accomplish certain things, I do exactly what it claims you shouldn't, and it works fine, and gives me cleaner code. I see no downsides, aside from MS not liking it.

I'm sure some of you might have differing opinions here, but, really, that isn't the point, this is just an example of what we're discussing.

----

So, back to my question, how seriously do you take it? Do you do everything it says(false positives not included, of course), or do you cherry pick, etc,. ?

I follow standards when they make sense, and have sound reasoning, etc, but, not when they're limiting my ability as a programmer for arbitrary reasons like:

Quote:
Info : "Public constructors for abstract types do not make
sense because you cannot create instances of abstract
types."

Your lack of creativity, and vision, is not my failing MS, why is this a standard? No one at MS ever thought of using an abstract class to abstract stuff? Really?

So really, this about standards, do you guys always follow standards, or do you go all rebel like me, and do your own thing when you think it's the right solution?

Posted 15-Jan-12 9:14am

Joe_Dert

Add a Solution

Comments

Andreas Gieriet 15-Jan-12 15:43pm

When you use FxCop (or any other tools that check the quality of the code by some heuristics and common rules), you as a development team/company have to decide what the aim is and which rules are mandatory (error) which are advised (warning) and which have no meaning to you at all (info/ignore). BTW: You may also define your own rules in FxCop. FxCop is a good framework for static code analysis, and it comes with a set of rules that MS regards as commonly good advise to follow. Not more nor less. For the given example: I agree with the resoning of MS, but the issue is of minor relevance, since usually you make abstract classes on purpose (not by accident) and the public constructors are not advised since a public constructor suggest that you can create an object by that constructor (therefore it should be protected instead). The rule does not complain about the abstract classes, it complains about the public constructor. Cheers Andi

[no name] 15-Jan-12 16:26pm

Well, I can certainly agree with all that. :)

Though, by the same logic, the warning doesn't make sense, and for the same reason, you can't instantiate an abstract class.

As you said it doesn't hurt to have it public, and it doesn't help to have it protected. (Anyone who thinks they can instantiate an abstract class, likely won't be deterred by semantics.)

But, yeah, I suppose overall it is correct in this case. (Though, it makes little difference.)

Anyways, this is getting off topic, the point of the discussion is to gauge how often programmers stick to standard vs. not.

Andreas Gieriet 15-Jan-12 16:44pm

FxCop rules are not a "standard" per se. You define in your team/company what "standard" is, i.e. what is commonly accepted as "standard". This is usually given by some development/coding/tools guidelines. They may be minimalistic or may be very elaborate. In order to have people "living" these "standards", you are better off, if you have tools supporting them... My experience: if you have elaborate rules in your team, then you need them checked by tools. And it helps if in your guidelines you have a disclaimer of the form: This is what we do here. Many of these rules were chosen arbitrarily, purely because SOME standard is better than none at all. If our rules disagree with the ones you prefer, it's nothing personal. While you work with us, use our rules. (this is a citation from C# Coding Guidelines which proved useful).

[no name] 15-Jan-12 17:06pm

Yeah, I suppose they're not hard standards, though, they must represent MS's basic ideals of "standards", to some extent.

At any rate, I really like that disclaimer, and thanks for the link, I'll check it out here in a minute. :)

---

I checked out the link, and it seems my ideals of standards mesh well with theirs, I do almost everything the same way. :)

Anyways, it was a good read, thanks. :D

Sergey Alexandrovich Kryukov 15-Jan-12 21:48pm

What a rare case: I voted 5 for this question! I explain why in my answer.

Cheers,
--SA

Sergey Alexandrovich Kryukov 24-Jan-12 22:29pm

Joe,

You might be also interested to see another discussion, this time about FxCop and StyleCop.
I answered and credited your question and your opinion; maybe you would like to case your opinion, too.

Please see:
http://www.codeproject.com/Questions/319430/Using-FxCop-and-StyleCop

Thank you.
--SA

[no name] 26-Jan-12 3:15am

Nice, thanks for the link, and credit, etc, though, it seems you and Andreas covered it, so there isn't much I could add at this point. :)

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Andreas Gieriet · Accepted Answer · 2012-01-15T10:19:00

Solution 1

See my comment above:

decide which FxCop rules are error, warning, to-be-ignored for your project/company
make sure all your ruleset files are according to your above mentioned assessment
take the error and warnings seriously

Cheers
Andi

Posted 15-Jan-12 10:19am

Andreas Gieriet

Comments

[no name] 15-Jan-12 16:41pm

It's nice to see this kind of attitude about it, rather than a hardline, you MUST do it this way because MS said so, kind of attitude. (Or whatever.)

Thanks for your time. :)

--

I'm leaving this open for the moment, I'd like to get some more opinions if we can. (Maybe links to articles, etc, on the matter too.)

I agree with your answer, and have used a similar method for years, but, I was hoping to get a wide range of feedback, from various devs world wide. (To see if any general consensus exist, or to see if it all just comes down to the individual devs\projects, etc,.)

Sergey Alexandrovich Kryukov 15-Jan-12 21:49pm

I agree and appreciate that you also agree with OP; voted 5 for this answer.

I found some rules idiotic and could bring compelling arguments against them. Please see my answer as well.
--SA

Andreas Gieriet 16-Jan-12 2:38am

Thanks for your 5!

[no name] 17-Jan-12 19:51pm

I've went ahead and accepted this as the solution, I had left it open for debate, but, it seems we all agree on the matter. :)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-01-15T15:47:00

I agree with you! I found some FxCop rules which are not just wrong, they are idiotic!

I remember another case. FxCop "thinks" that the "out" parameters is a sign of a design flaw. In my strong opinion, this would make sense for some languages, but as C# requires "out" keyword in both signature and calling code, all the problems are eliminated. There are many cases when "out" is better than anything else.

I used to see many problems like that. As the one you pointed out, I faces with that, too, analyzed it and came to the same conclusion as you did.

At the same time, FxCop can be very useful. It found out many problems I failed to see with naked eye, such as performance (a simple thing, missing "static" in methods not using "this" — apparently my mistake), spelling and a lot more.

Conclusion: use FxCop but fine-tune the project options and eliminate those idiotic rules from your practice. This is what Joe advised you, too. If you use FxCop in this way, it will can be for help, not for hassles.

—SA