Add ExplicitInitRule

[mtaube]

Hey guys, I added a quick rule to discourage the explicit use of init (#672). The current implementation only catches inits that are prefixed by a well-formed class / struct name.

// bad
let abc = Abc.init()

// good
let abc = Abc()

[codecov-io]

Current coverage is 88.64% (diff: 100%)

No coverage report found for master at ed73db3.

Powered by Codecov. Last update ed73db3...5f27267

[jpsim]

Do people really write Abc.init() superfluously? Since there are legitimate uses (e.g. optionalString.flatMap(NSURL.init(string:))) that would trigger this warning, I'd be inclined to not add this rule.

[mtaube]

I've seen some people at work do it, especially developers migrating from Obj-C. Also I think it might be because of Xcode autocomplete combined with laziness. Which is why I want to enforce with this rule on everybody.

What do you think about:

1. Making it opt-in
2. Creating a blacklist for the rule to allow for the .init, like the NSURL. I can't think of other cases where this would trigger false positives.

[jpsim]

We could make this opt-in. I'm generally more ok with false positives with opt-in rules.

Don't special case NSURL, there's nothing unique about it when it comes to using its initializer as a function reference.

[mtaube]

@jpsim made this rule opt-in / correctable, lmk what you think

[jpsim]

missing two trailing spaces according to the guidelines at https://github.com/realm/SwiftLint/blob/master/CONTRIBUTING.md#tracking-changes

[jpsim]

I'm still pretty dubious of the value of such a rule, but since it's opt-in and if some find it useful, then why not.

@mtaube please address my latest round of comments and rebase this so I can review again.

[mtaube]

@jpsim made those changes. Lmk if anything else is needed. Thanks for SwiftLint / Realm by the way – we use both at work.

[norio-nomura]

Thanks for doing this! 🙏
I have rewritten this as ASTRule for reducing false positive on #826, and merged that.