[swift-evolution] "bad smells" should be compiler errors with suggestions on how to fix them
clattner at apple.com
Sun Dec 6 00:15:14 CST 2015
> On Dec 5, 2015, at 12:54 PM, Alex Blewitt via swift-evolution <swift-evolution at swift.org> wrote:
> Sent from my iPhat 6
> On 5 Dec 2015, at 19:23, Adrian Kashivskyy <adrian.kashivskyy at me.com <mailto:adrian.kashivskyy at me.com>> wrote:
>>> SwiftLint looks really nice, but one thing I'd really like is automatic formatting.
>> That's a feature of IDE, not the language itself.
> Not necessarily. The existence of "go fmt" has resulted in teams running it as a pre-commit translation and as a way of standardising across all users, regardless of IDEs. Otherwise you end up with multiple IDEs (like Eclipse and IntelliJ) which do formatting slightly differently and lead to all manner of pointless arguments.
> Letting "the IDE" do formatting is fine provided there is a maximum of one IDE.
Just to chime in on this thread with some guidelines for thought:
1) The compiler does have some code smell warnings (e.g. unmutated var -> let).
2) It is really important that these be warnings, not errors. Turning them into errors makes refactoring code a pain (as commonly complained about in the go community).
3) By doing these sorts of things, the compiler needs to be conservative in its policies - the policies that it enforces has to be unquestionably the right thing to do.
Separate from compiler-enforced policies, I’d *love* to see someone tackle implementing a "go fmt” analog that reformats Swift code into a standard style, as well as a “clang format” tool that could be used by IDEs for on-the-fly editing of code, as well as a “linter” / static analysis tool which can flag potential issues while having a higher tolerance for false positives. These should be separate from the “always on” compiler diagnostics though.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution