Objective-Clean and SwiftLint
Objective-Clean and SwiftLint are apps which help facilitate automatically checking style in Objective-C and Swift (respectively). When set up properly with the Vokal style files, these apps will give you warnings for various style inconsistencies.
We have a site license available for Objective-Clean and SwiftLint is open source, so they are both free for any engineer at Vokal to use. Their use is therefore strongly encouraged.
Download the trial version of Objective-Clean from the website. Upon running the app successfully, a dialog box will appear in which you can enter our license information.
Note that the style files do not cover all of our code standards, since Objective-Clean and SwiftLint only cover certain formatting options. You and your code reviewer are still responsible for keeping an eye out for anything the app might have missed. It is, however, a great way to keep from getting "Hey, you missed a bracket on the wrong line" comments in code review.
If nobody on your project has already set up Objective-Clean or SwiftLint, the steps to do so are pretty simple. Here are the steps for both apps:
- Drop the Vokal Objective-Clean style file into the same folder as your
- Fire up the Objective-Clean desktop app. The app must be in your Applications folder rather than Downloads. Receiving a script warning after running your Xcode project is an indication that the app is in the wrong folder.
- Drag and drop the
.xcodeprojfile into the desktop app's "Add a project" window.
- If you're using any third-party libraries not through CocoaPods (which are ignored by default), add your
Libsfolder to the comma-separated list of folders which should be ignored, so you only get warnings about your own poorly-formatted code instead of third party poorly-formatted code.
- If you're using MOGenerator, Cat2Cat, or any other automatic code generation tool, make sure you add the machine-generated files folder to the ignore list for the same reasons.
- Hit the Install Run Script button.
- The first time you build locally after installing the script, you'll get a dialog asking for confirmation of which folder to scan (due to sandboxing restrictions). Confirm, and then you're off to the races.
Make sure you commit your Style Settings file with the project so all members of a team are getting warnings based on the same style.
- Copy the Vokal SwiftLint yml file into the same folder as your
.xcodeprojfile. Since this file is coming from the Vokal template, you will need to change the instances of
___PACKAGENAME___with the name of the project.
- Add an Xcode build phase named "SwiftLint Run Script" with the contents of the script:
pod 'SwiftLint'to the
bundle exec pod install.
- Build the project and SwiftLint should now run on every build. You can check the Xcode build log messages to verify that files are being linted.
Ignoring Specific Lines
Note that if you ever need to have Objective-Clean skip a part of your file because you're breaking the rules for a good reason, you can force it to skip with a specially formatted comment:
//##OBJCLEAN_SKIP## //The code you want to ignore //##OBJCLEAN_ENDSKIP##
With SwiftLint, you specify the rule you want to ignore in balanced
swiftlint:enable comments. In the example below the
force_cast rule is being ignored:
//swiftlint:disable force_cast //The code you want to ignore for the force_cast rule let foo = NSNumber() as! Int //swiftlint:enable force_cast
If you want to prevent Objective-Clean from throwing a warning when it runs on a computer without the appropriate app installed, update the warning line which is added by the app to instead just echo the following:
echo "NOTE: You have to install and set up [app name] to use its features!"
More documentation is available at the Objective-Clean site and the SwiftLint site.
- We have not set up Objective-Clean on our CI server - the warnings this tool generates will not wind up as part of your automated test coverage. The SwiftLint binary is added to the repo and will run as a build phase both locally and on the CI server.
- Remember: This only covers a subset of our code standards. You are still responsible for following any standards not covered by the style file.