Because style matters
Despite having a proper code style documented and code conventions based on guidelines in place, developers might forget to work apply it consistently or just become lazy and start to neglect it. Either way you don’t want to spend your time fixing the code style yourself or asking colleagues to do it.
Code styling is (despite important) one of least crucial tasks of coding, and therefore it’s recommended to let the tools do the pedantic formatting checks for you, allowing you to focus on the more tricky aspects of writing code.
Realm introduced a pretty nice tool to help automate the linting process — SwiftLint.
In this article I will explain you how to setup this tool in your iOS project in order to give the semantics you want, Protect code cleanliness and help you write cleaner code in general.
SwiftLint
Swiftlint is a tool that helps you to identify and flag parts of the code that may not follow the style guidelines defined by you.
If you don’t have SwiftLint already installed go and check the installation section in the original repo.
You can use it by adding a run script to Build Phases in your Xcode project.
Below, you’ll find the script we use in order to check our code style. Go ahead and use it in your project by saving it to your project directory: $SRCROOT/Build-Phases/swiftlint.sh
Before we dig deeper, let me quickly explain the script a little bit as it’s a customized edition from the one you can find in the github repo 👇
The swiftlint-original.sh script will show warnings and errors displayed in the IDE for every single file in the project, which is a bit annoying. Instead we decided to show warnings and errors only for (added, modified and copied) files from git diff. Also we this other check to run the script in Debug mode only:
if [ "${CONFIGURATION}" = "Debug" ]; thenNow that you have the script in your project directory and understand it, go and select your project then Build Phases > New Run Script Phase
In this step can copy and paste the script itself to your Run Scrip Phase, but we recommned to keep the script in a seperate file (becuase you might use it in another target in the project). So go drag and drop your file into the Run Script or writer it’s path as below:
Having this script will visually show you what exact parts of your code aren’t conform the style that you decided to stick with, every next time you build the project.
The image below shows you an example of warnings and a violation of one of the rules we defined in our Style Guide configurations file.
SwiftLint will really help you enforcing yourself and your colleages on sticking to the style guides that are agreed on by the team, having the positive effect on the team as they won’t have any reason left for discussions caused by two people using different code style practices. This is where automation comes in handy, by having the machines do all the heavy lifting for us. Leaving us, as developers and code reviewers, to really focus on the important parts.
The main goal is to enforce and encourage the use of stylistic conventions, which are generally defined by the community or the team. All to result in code style consistency between a single project’s files or between projects in general, whether it’s your personal project or the company’s. It will also help to provide more readability of the project and many more benefits.
Where to go from here:
Read more about SwiftLint, and check out what rules it provides. Build your own style guide with your team and configure it in the .swiftlint.ymlfile to use it across your projects. Learn more about other ways to use SwiftLint (like using it with github and post wanrings on every pull request using danger.)
Reference:
👏🏻 if you enjoyed this article and found it useful. This will encourage me to write more! Any comments or feedback is appreciated!
Feel free to add me on github, twitter, or linkedin.
