Make rule file_name accept the ending Extension for extensions

[Jeehut]

Currently the rule file_name shows a warning when there's a file named BoolExtension which looks like the following:

extension Bool {
    /// Equivalent to `someBool = !someBool`
    ///
    /// Useful when operating on long chains:
    ///
    ///    myVar.prop1.prop2.enabled.toggle()
    mutating func toggle() {
        self = !self // swiftlint:disable:this toggle_bool
    }
}

Extensions are either named <Type>Extension or <Type>+MyProject in the Swift community which I think should both be exceptions in this rule. As far as I could see, there's already an exception implemented for the latter, but not for the first.

I highly recommend to make this acceptance the default behavior as in my opinion these are false positives. But we could also make this a configuration option if really need be ...

[marcelofabri]

Can you point to some projects that use this convention just for future reference?

[Jeehut]

Now that you asked the question I looked it up and couldn't find many bigger projects using this naming convention. I could swear this was a thing at some point, but it seems I'm the only one using this style, for example here, there and there.

Now I'm not so sure about making this the default behavior any more, we could also make it an option. But on the other hand it wouldn't hurt to allow the ending Extension, would it? Not sure what to do ...

[marcelofabri]

I'm wondering if we should support a more generic allowed_suffixes property instead. This would be more flexible and extensible.

[Jeehut]

Sounds good to me. That would be an array of strings then, no? I'm going to implement it that way later this day and update this PR accordingly.

[ornithocoder]

The project I'm currently working on uses Extension*. For the example above it would be ExtensionBool.swift.

[Jeehut]

Okay, then let's add allowed_prefixes as well.

[Jeehut]

@marcelofabri @ornithocoder I just updated my implementation in this PR to support two new options:

• prefix_pattern: Allows to specify a regex pattern which matches the part before the type name.
• suffix_pattern: Allows to specify a regex pattern which matches the part after the type name.

For me, I would need to specify the following to get my expected behavior:

file_name:
  suffix_pattern: "Extensions?|\\+.*"

For @ornithocoder this could be the following:

file_name:
  prefix_pattern: "Extension"
  suffix_pattern: ""

Please note that the current behavior of accepting a +Something suffix is now the default suffix pattern, but can be turned off by specifying a different suffix_pattern. In the first example configuration above, I'm keeping the default pattern and adding the suffix Extension as an allowed one. In the second example I'm explicitly specifying an empty string to suffix_pattern so the default behavior is turned off and the prefix_pattern is accepted only.

I think this is the most customizable solution, both allowing defining custom allowed prefixes and suffixes using regexes and additionally giving the option to turn the default suffix behavior off, if needed.

[dregatos]

Hi @Dschee,

I am confusing about the prefix_pattern and suffix_pattern implementation. How could I avoid to see the file_name warning on a file named UIApplicationExtensions.swift? I tried to apply this regex pattern \\+.*|Extensions?\.swift with no luck :(

[Jeehut]

Hi @dregatos, you don't need to put in the .swift part at the end, it's not part of the file name. Also note, that the part not covered by the prefix will still be checked by the file_name rule. So you would still need the type UIApplication in your file. If you don't have it, I recommend you use the option excluded instead. See an example here.

[dregatos]

Hi @dregatos, you don't need to put in the .swift part at the end, it's not part of the file name. Also note, that the part not covered by the prefix will still be checked by the file_name rule. So you would still need the type UIApplication in your file. If you don't have it, I recommend you use the option excluded instead. See an example here.

Thanks a lot for the help!!