Today’s post on SwiftLint over at Natasha (The Robot) Murashev’s This Week in Swift inspired me to stop complaining abut lint issues and start building. While I love the idea behind SwiftLint, I didn’t entirely love the implementation or the rules.

I wanted something good enough to be used today with real code, even in imperfect form. It had to run from the command line and work with playgrounds. It had to be able to scan files added to Xcode projects by reference as well as those physically stored in the $SRCROOT.

A while back I built an Xcode Manifest app to compare file references in code to all files used within a project. I re-purposed some of that project, added basic rules using regexes, and found myself more reasonably pleased with the results.

You can test the utility for yourself. Either call from the command line, e.g. “./testlint .” or add to a build phase.

To override any warning, add nwm somewhere on the line, e.g. // nwm.

If I ever get around to really building this, I would add an optional config file into Xcode projects and command-line options, enabling you to tweak which warnings to include and which to skip.

My list is obviously pretty primitive but I’m happy that I made the effort. It’s already catching several of my biggest bugaboos, specifically parens after ifs, stray semicolons, and unneeded enumeration prefixes — the last of these having taken the most time to implement.

Without some serious re-tinkering, this utility probably will not be able to be grown into finding unneeded class references for constructors or extraneous self references outside inits and closures.

But for an afternoon between dropping off kids and picking them up, I’m pretty satisfied.

Note: I’ve been updating both the build and the gist, so you may want to refresh, re-look, and test with newer versions.