Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rule Request: strict_accessibility_modifier #4839

Open
2 tasks done
mildm8nnered opened this issue Mar 25, 2023 · 1 comment
Open
2 tasks done

Rule Request: strict_accessibility_modifier #4839

mildm8nnered opened this issue Mar 25, 2023 · 1 comment
Labels
discussion Topics that cannot be categorized as bugs or enhancements yet. They require further discussions. rule-request Requests for a new rules.

Comments

@mildm8nnered
Copy link
Collaborator

New Issue Checklist

New rule request

strict_accessibility would warn where the current accessibility modifier was less restrictive that it could be, given the rest of the codebase.

By enforcing accessibility strictly, declarations allow inference about how the code is used, as opposed to how it could be used.

For example, consider

class Foo {
    var bar: Int = 0
}

here bar is visible as internal by default, but if it is never actually accessed outside its own class, then it could equally be declared as:

class Foo {
    private var bar: Int = 0
}

This makes intent clearer.

This would presumably need to be an analyzer rule.

  1. Why should this rule be added?

Enforcing accessibility as tightly as possible makes intent clearer, and can potentially help the compiler.

  1. Provide several examples of what would and wouldn't trigger violations.

Triggering Violations:

↓class Foo {
    // if Foo can safely be private
}
↓public class Foo {
    // if Foo can safely be internal
}
class Foo {
    // if bar can safely be private
    ↓var bar: Int = 0
}
public class Foo {
    // if bar can safely be internal
    ↓public var bar: Int = 0
}

Non-Triggering Violations:

Exactly as the triggering violations, but where the rest of the code determines that Foo or bar must be internal, or private, or whatever.

  1. Should the rule be configurable, if so what parameters should be configurable?

Possibly configurable for which modifiers should be reported on. For example, warn me about public's, but don't warn me about internal's - I'm not sure I can see a use case for that though.

  1. Should the rule be opt-in or enabled by default? Why?

Analyzer rule, so automatically opt-in I believe.

@SimplyDanny
Copy link
Collaborator

Do you know of Periphery? It perhaps already supports all that or could (more easily) be extended to do so. SwiftLint would have to reimplement what Periphery already provides.

@SimplyDanny SimplyDanny added rule-request Requests for a new rules. discussion Topics that cannot be categorized as bugs or enhancements yet. They require further discussions. labels Mar 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Topics that cannot be categorized as bugs or enhancements yet. They require further discussions. rule-request Requests for a new rules.
Projects
None yet
Development

No branches or pull requests

2 participants