[swift-evolution] "bad smells" should be compiler errors with suggestions on how to fix them

[Jean-Pierre Simard]

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


I agree that a compiler cannot be too stylistically opinionated, and that
an opt-in, standalone linter/formatter is preferable.

As others have mentioned, there's a community-built tool called SwiftLint
<https://github.com/realm/SwiftLint> that does much of this today. It's an
AST-assisted tool to enforce code style conventions & automatically correct
certain violations. Rules can be enabled/disabled and parameterized either
inline in the source or via a YAML configuration file.

One of the tool's main limitations so far is that the Swift AST it operates
on is obtained from a reverse-engineered SourceKit interface and is
incomplete.

Myself and other SwiftLint contributors intend to replace the
reverse-engineered SourceKit backend with more official tooling that was
just open sourced, which will enable SwiftLint to do things like an
opinionated go-fmt/clang-format style formatting (source->AST-source) and
some types of static analysis like identifying cyclomatic complexity.

One thing I'd like to discuss with relevant Swift project owners (notably
Argyrios and Chris) is the possibility of moving SwiftLint development into
github.com/apple, which would increase the tool's exposure and pace of
development. I hope to make a more official proposal for how that
transition could happen in the upcoming week, probably in swift-dev.

On Sun, Dec 6, 2015 at 9:07 AM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> wrote:

> On Dec 5, 2015, at 11:15 PM, Chris Lattner via swift-evolution <
> swift-evolution at swift.org> wrote:
> > 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.
> >
> > -Chris
>
> I have a fairly minimal held-together-by-bandaids linter I put together:
>
> https://github.com/erica/testlint
>
> I have hesitated to develop it much further because I didn't want to be
> committed to inter-process SourceKit hacking and did not yet have access to
> a reliable parse tree. In its current state, it's a regex-based
> line-by-line scan.
>
> The rules it follows are here:
> https://github.com/erica/testlint/blob/master/testlint/sources/Linter.m
> with fairly copious commenting
>
>
> -- Erica
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151206/f816565a/attachment.html>