Analyzer proposal: Don't use 'public' on members of internal types

Or more generally: “Avoid visibility modifiers that exceed their effect”

Internal types may contain public members if those members implement interfaces. Aside from that case, public members in an internal or private type are in fact not public at all, but internal.

During code reviews seeing an added or changed public member can set off alarm bells to reviewers who are keen to watch the evolution of a library’s public API. It’s an extra load on them to see public on a new member only to later realize that the container itself is internal or private and thus not worth an API review.

An analyzer should prevent liberal use of public where internal would be equivalent.

[sharwell]

I’m concerned the interface implementation limitation would be sufficiently impactful as to undermine the intent of the rule. Other approaches, including but not limited to PublicApiAnalyzer, are superior for tracking changes to the public API surface.

For teams that implement public APIs first as internal types and then move to public types after review, the use of public methods to designate eventual public APIs of the types could be beneficial.

On the other hand, projects that have no public API by design, this has the interesting side effect of becoming a rule that simply reveals interface implementations.

Design questions:

1. How would this work for members of nested types? For example, members of protected types nested in an internal type would have a maximum accessibility of private protected, which impacts members declared public, internal, and protected.

[JohanLarsson]

@AArnott wrote it like this: https://github.com/GuOrg/Gu.Analyzers/pull/217 We can move it here if it is decided that there will be a cop rule for it.