Check for redundant internal and fileprivate #605
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As somebody brought up a while ago in this discussion, I've long felt it would be great to be able to highlight code that is more public than it ought to be. For instance,
static
(implicit or explicit) that really ought to befileprivate
orprivate
; orfileprivate
that ought to beprivate
. (Note that periphery already checks for redundantlypublic
declarations.)Since @ileitch agreed that it would be a good feature, but hasn't had a change to get around to it in almost 2 years — my how time flies — I thought I would take a crack at it.
I think I have it working pretty well. There may be some corner cases I haven't considered; especially considering that there is some code in
RedundantExplicitPublicAccessibilityMarker.swift
(upon which much of my code is based) that I couldn't quite figure out if it needed to be brought over to the other tests.One limitation that I haven't figured out a workaround for is when an implementation of a protocol needs to be have comparable visibility and thus shouldn't generate a warning if it's internal scope. The code can confirm if it's a protocol defined in the code, but if it's an API protocol (such as conforming to AppKit or UIKit) then we can't get to the
Declaration
given aReference
. Maybe there is a technique that I couldn't figure out. For now, I figured it was safer to not treat this as a problem if we can't find the reference, rather than generate an annoying false positive.Hopefully this is close to mergeable. There are probably some conventions that you'd like to stick to that I wasn't aware of, so I'll be happy to tweak it a bit … Or maybe it's just the foundation upon which further improvements can be built.