-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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: Warning for extensions used for grouping code #1767
Comments
This should be a good starter rule if anyone wants to grab it (as long as it catches only extensions/classes in a single file). It definitely should be opt-in though. |
So what would you want the rule to catch? Extensions on a class in the same file where the class is declared? |
@Uncommon Yes. |
I thought about triggering for multiple protocol extensions, but then realized it would require checking for any possible specialization that would require extensions to be split up... Seemed not worth investing in right now. |
@marcelofabri I don't believe this was implemented as @kurabi requested. The request seems to be to only trigger on groupings that are purely organizatonal extensions, without any protocol conformance, e.g: class Foo {
}
// MARK: - Private
extension Foo {
} The rule shipped in 0.22 matches any extension. |
He wrote:
Anyway, feel free to submit a PR with this as a configuration if you'd like 👍 |
ah yes, I must have glazed over that part 😟 |
@ileitch The intention was to also flag extensions that implement a protocol too because of the same drawbacks (if not more) as mentioned above. |
Has this been implemented yet? |
@whoyawn https://github.com/realm/SwiftLint/blob/master/Rules.md#no-grouping-extension |
Swift Extensions are often times used in 3 ways (there are more):
The use of swift extensions for with regards to point 3 above is very trendy right now and I feel strongly that it is incorrect and has drawbacks. A simple
// MARK:
achieves the “code organization” intention of using extensions.Reasons to not use extensions for organizing code within the same file:
Objective-c has categories offer ability to be named yet this pattern isn’t trendy there, suddenly its trendy in Swift.
Extensions are awesome, so to be clear, this proposed swift lint rule would only apply to this trendy usage of extensions for the above drawbacks mentioned above.
The text was updated successfully, but these errors were encountered: