Add nested type handling specification to file_name rule

[fredpi]

Closes #2717.

[SwiftLintBot]

	12 Messages
📖	Linting Aerial with this PR took 3.49s vs 3.15s on master (10% slower)
📖	Linting Alamofire with this PR took 5.79s vs 5.13s on master (12% slower)
📖	Linting Firefox with this PR took 17.36s vs 15.06s on master (15% slower)
📖	Linting Kickstarter with this PR took 27.5s vs 27.19s on master (1% slower)
📖	Linting Moya with this PR took 2.42s vs 2.3s on master (5% slower)
📖	Linting Nimble with this PR took 2.24s vs 2.26s on master (0% faster)
📖	Linting Quick with this PR took 0.8s vs 0.83s on master (3% faster)
📖	Linting Realm with this PR took 3.83s vs 3.75s on master (2% slower)
📖	Linting SourceKitten with this PR took 1.53s vs 1.55s on master (1% faster)
📖	Linting Sourcery with this PR took 5.02s vs 4.99s on master (0% slower)
📖	Linting Swift with this PR took 39.57s vs 38.76s on master (2% slower)
📖	Linting WordPress with this PR took 29.97s vs 29.7s on master (0% slower)

Generated by 🚫 Danger

[fredpi]

Any thoughts on this? ;)

[jpsim]

Thanks for the PR! What are your thoughts on just allowing both dots and no dots without necessarily adding a configuration option for it?

IMHO that would follow the mantra of "don't let your tools get in your way" a lot better than requiring a strict consistent format for nested type extensions.

[fredpi]

@jpsim This was my first thought as well, but then I figured that one could already exactly specify prefix and suffix patterns, so I thought making the nested type separator just as configurable would make sense (considering that some may also prefer other separators than or . (e. g. _)).

However, I don't care very much about this myself, I just wanted to follow the existing pattern of configurability. If you prefer just allowing certain characters (dot / underscore / no char), I'd happily adjust the PR accordingly. 😉

[jpsim]

Good point on aligning with the other configurability options. Thanks for the PR @fredpi!