Rule Request: Warning for extensions used for grouping code

[kurabi]

Swift Extensions are often times used in 3 ways (there are more):

1. Retroactive Modeling
2. Protocol Extensions
3. For organization purposes, where grouping a set of methods together within the same file that declared that class. For example, grouping private methods in an extension, or an extension to implement each protocol that the class implements.

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:

• Unlike MARKs, they do not show up in the source editor summary dropdown in Xcode. (Screenshot: https://goo.gl/T5vkr7)
• Must scroll through the file to find all protocol conformances
• Extensions obviously can’t override methods, hence this limits how these groups are composed
• Can’t add properties to extensions, so grouping is somewhat false and not always fully contained as they may suggest
• Take more space than MARKs and not as concise
• Lead to longer compile times (I am finding a source for this)
• Myth: Extensions don’t fully force protocol conformance to be in the scope of that extension
• Myth: They do not give ability to implement protocol privately

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.

[marcelofabri]

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.

[Uncommon]

So what would you want the rule to catch? Extensions on a class in the same file where the class is declared?

[kurabi]

@Uncommon Yes.

[Mazyod]

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.

[ileitch]

@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.

[marcelofabri]

He wrote:

For example, grouping private methods in an extension, or an extension to implement each protocol that the class implements.

Anyway, feel free to submit a PR with this as a configuration if you'd like 👍

[ileitch]

ah yes, I must have glazed over that part 😟

[kurabi]

@ileitch The intention was to also flag extensions that implement a protocol too because of the same drawbacks (if not more) as mentioned above.

[whoyawn]

Has this been implemented yet?

[piobyz]

Has this been implemented yet?

@whoyawn https://github.com/realm/SwiftLint/blob/master/Rules.md#no-grouping-extension