Swift and the Style Guide
A great approach for teams with more than one developer is to enforce code style usage. In my team, robots helps make the code in the project conforming. For Objective-C projects we always had clang-format and OCLint. For Swift projects other guides and other tools.
There are three acknowledged Swift style guides: Ray’s, GitHub’s, and LinkedIn’s. On my taste, first one is a thing for web-sites; GitHub guide is incomplete; the last one is my preferred. For the great good we have to enforce use the chosen guide, so no one can push wrong-styled code.
We use SwiftLint static analyzer to indicate code smell issues like too complex functions, too big classes, bad naming, etc.
We use SwiftFormat on every ⌘B to make the code conform to the style guide. This build phase auto-formatting the code in changed files if needed. Eventually I’ll move it from building proccess to a pre-commit hook. But now team members will know how exactly the code will be changed, no doubts.
Both tools takes avg. 1…3 sec to execute on 500+ files in project.
For new projects is handy to use these tools since initial commit. For existing project one’s have to make the auto-formatting commit where all files would be modified on their behalf.
The .swiftlint.yml is below. Disabled disabled rules are kept for instance.
