CA1811, AvoidUncalledPrivateCode: Separate private & internal?

Question

I've been running FxCop on a managed assembly we build for a couple of days now, and something has struck me about the AvoidUncalledPrivateCode Performance rule. While it took me a bit to understand why internal members would be flagged alongside private members, I'm still left wondering if perhaps they shouldn't be separate rules.

To give some context, our project is a managed assembly that serves as an API for an unmanaged product. As such, there are a number of specific constructors and methods that have to be kept as internal-only, but serve a greater breadth of functionality within the library and can/will be used in the future. While I see the logic in flagging both types by this rule, in my context I would draw more of a distinction between internal and private class data and would prefer to flag one but not the other. Any thoughts on whether that would be a valid option, or is there some other reason I don't see as to why it would be prohibitive to flag one but not the other?

I realize it's probably nit-picking a bit, but I figured I'd ask.  :-)


Thanks,
Mike

Answer 1

Hello Mike,

I am very glad you noticed both private and internal are violations of the rule number CA1811 and post it here.
Basically, when we do code analysis on our assemblies, for rule CA1811, it will analyze wethere the member is visiable outside the assembly by using a property called IsVisibleOutsideAssembly. Hence, members with private or internal keyword were considered. As we could see, private member and internal member were not considered seperately when designing the rule.

Currently, I did not see any option in Visual Studio to flag only one of them but not the other. However, we could write a custom rule for that. The follow link contains walkthroughs ans sample of custom rules, I believe it is helpful for writing custom rules:
http://www.binarycoder.net/fxcop/

Best regards,

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.
If you have any feedback, please tell us.
Welcome to the All-In-One Code Framework!