coveragepy VS SwiftLint

Coverage.py is the go-to tool for measuring code coverage of Python programs. Once installed, you can use it with either unittest or pytest.

Code Coverage Analysis assess the code portions tested by the current test suites without altering the code.

The PLASMA lab @ UMass Amherst (home of the Scalene profiler) has released a new version of Slipcover, a super fast code coverage tool for Python. It is by far the fastest code coverage tool: in our tests, its average slowdown is just 5% (compare to the widely used coverage.py, average slowdown 218%!). The latest release performs both line and branch coverage with virtually no overhead. Use it to dramatically speed up your tests and continuous integration!

Tests ensure the tested behavior is maintained. It's up to the developers to write tests with sufficient coverage. Determining which lines of code on your project are covered by tests is easily quantifiable using tooling. E.g. https://coverage.readthedocs.io/

Taking the idea further, if you build robust tests for your API, you could use a dynamic code analyzer like coverage or figleaf to identify and delete unused functions.

coverage

FWIW, ternary expressions aren't properly detected by coverage: https://github.com/nedbat/coveragepy/issues/509

SwiftLint is a big one.

I actually don't see anything worth changing. It looks good to me. I think the most important thing is just to maintain the constructive attitude you already have about future-you dealing with the code, because only future-you will really know where you could have done better. One personal-preference thing I carried over from working on Go code is to look for a tool like gofmt [1,2] for Swift. I've been using swift-format [3] for about 2 years and haven't been dissatisfied enough to reach for something more fully featured like SwiftLint [4]. I didn't like the idea at first of delegating most formatting control over to a tool designed with someone else's subjective idea of formatting. But my feeling afterward was that it was freeing: it was no longer (completely) my job/burden/responsibility. An "assistant" would clean up the formatting of my code every time I saved the file. That's a nightmare if you can't configure the tool as much as you need, but if you're lucky and find a configuration you can live with, it lets you focus more on naming and other conventions that aren't so easily automated (yet). [1] https://go.dev/blog/gofmt [2] https://twitter.com/bitfield/status/953395343353315329 [3] https://github.com/apple/swift-format [4] https://github.com/realm/SwiftLint

iOS SwiftLint

1) Here are some tips & tricks for refactoring: https://developer.apple.com/documentation/xcode/finding-and-...

The “rename in project” or “rename in scope” functions are quite neat.

2) Check out SwiftLint: https://github.com/realm/SwiftLint

I have not used it in a while, but it comes with good defaults and is highly customizable to your own preferred Swift style.

Check this as well https://github.com/realm/SwiftLint

Try SwiftLint. https://realm.github.io/SwiftLint/

if which swiftlint >/dev/null; then swiftlint else echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint" fi

SwiftLint - A tool to enforce Swift style and conventions. Language: Swift.