ProtectionTooPermissiveRule

[Vlad]

I would like to increase the protection wherever possible to private
if possible i.e. a rule that identifies all Methods, properties, even
variables and anything else applicable that are declared with too
generous a protection level.

I understand that for libraries that expose functionality, it is
necessary to permit access. If I claim that the scope of use is
limited to a solution (set of exe and dlls), is it possible to write a
rule that warns me when Public is used instead of Internal is used
instead of Protected is used instead of Private when greater
protection would still allow the solution to compile?

Warnings like "Method Foo() could be private instead of public" or
"Variable bar could be protected instead of internal." would be really
cool.

Thanks,

Vlad

[Sebastien Pouliot]

Hello Vlad,

On Jan 8, 1:30 pm, Vlad <vladimir.giszp...@gmail.com> wrote:
> I would like to increase the protection wherever possible to private
> if possible i.e. a rule that identifies all Methods, properties, even
> variables and anything else applicable that are declared with too
> generous a protection level.
>
> I understand that for libraries that expose functionality, it is
> necessary to permit access. If I claim that the scope of use is
> limited to a solution (set of exe and dlls), is it possible to write a
> rule that warns me when Public is used instead of Internal is used
> instead of Protected is used instead of Private when greater
> protection would still allow the solution to compile?

Yes. Currently no Gendarme runner support a concept of "assembly
group" (or solution), but this is something we discussed because it
affects some existing rules (like some smells). Without this concept
it's hard to report something useful - at least for this test case...

> Warnings like "Method Foo() could be private instead of public" or
> "Variable bar could be protected instead of internal." would be really
> cool.

Still some cases are valid without any "grouping" concept. For example
an internal method (or field) that isn't used outside it's type could
(or should ;-) be private - well unless the assembly has a
[InternalsVisibleTo] attribute.

Making a list of test cases would be useful before working on this (if
you or anyone else is interested) and/or add the ideas to our Rules
document (so the idea doesn't get lost). We already have a few rules
that are, logically, similar to this one, e.g. unused private code,
uninstantied internal classes.

Sebastien