StyleCopAnalyzers: 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.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 3
- Comments: 15 (9 by maintainers)
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:
protectedtypes nested in aninternaltype would have a maximum accessibility ofprivate protected, which impacts members declaredpublic,internal, andprotected.@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.
I’m quite likely to write this analyzer myself as it’s a big annoyance to me during code reviews.