(1) Background
I wrote an article about SwiftLint about two years ago. I have to say that the idea at that time was very rough, but at least it gave me an enlightenment. In the past year, the company has started to build its own centralized CI, which has also been promoted to all teams, and has benefited a lot from participating in it. Lint, as an important part of CI, naturally has a lot of value output, but with the daily in-depth application, I still think about the practice of Lint in the company team, which can be regarded as a supplement and expansion of the article two years ago.
(2) Defects and pain points
Cost, I have to say, is the biggest barrier to getting people to use SwiftLint.
1. The cost of being proactive
If we were to use the command line tool of SwiftLint directly to normalize code, each time we would automatically think “oh ~ I need to do Lint once”, and then I would execute “SwiftLint” once. For humans, the act of active recall is very high. In product development, we always say that customers are lazy, and we developers are lazy too.
2. Cost of building a configuration file
If we did use SwiftLint, it would be big and comprehensive as a tool, however, it would be a “big deal” for every technical team, and few projects would want to use SwiftLint’s rules in their entirety, most of the time we just want the rules we need. While SwiftLint supports customizing rules by editing configuration files, it is often the case that a team is working on multiple projects at the same time, and if we had to edit a configuration file for each project, no one would want to do the mechanical work.
3. Cost of team standardization
On the team dimension, we want everyone to use the same specification so that the code submitted is not all over the place. However, due to the nature of the SwiftLint configuration file, there is no way to standardize the code style rules for the entire team in the current way.
4. The limits of CI
It is true that CI can solve certain problems, through CI we can construct a standard process, through a unified standard for every MR/PR code to lint. However, unfortunately, CI also has its own limitations. First of all, no matter how much notice is given, there is still the problem of human initiative. Even if the parties are informed of the problems in the submission by nails or emails, the warning may be ignored due to the “inertia” of human beings. In addition, the CI operation must be done after the commit. Even if you are a person with strong self-drive, you will carefully modify the CI rule violation every time, but too many code style fixed will pollute the whole Git log. Therefore, the delay of CI is also a disadvantage that cannot be ignored.
(III) Team practice: SafeCommit
In view of the above defects, our team plans to build a SafeCommit tool. In our plan, not only the code verification, but also the commit verification, so as to unify the team’s commit style.
Whenever we need git commit, we use Git sc instead. At this point SafeCommit will lint the added file, if it is a Swift source file then it will lint, otherwise skip. If it is found that the current file did not pass Lint, the result is printed to the window.
Git commit-m ‘XXXXXXX’ : git commit-m ‘XXXXXXX’ : git commit-m ‘XXXXXXX’ : git commit-m ‘XXXXXXX’ Git logs are very neat when viewed.
After entering the commit content, the commit is complete.
By the way, GUI tools such as SourceTree are also supported.
(iv) Problems solved by SafeCommit
passivity
Since SafeCommit is implemented via Git hook, the original engineers’ active calls to Lint have been changed to passive lint at commit time, which greatly takes care of the “lazy” nature of engineers. Also, the git hook implementation will trigger lint for code and commit information, even if you commit via the native git commit command instead of using git SC (of course, all this is provided that you have run git SC at least once in the repository).
Low cost & low intrusion
SafeCommit doesn’t make any changes to your repository by default, and we don’t need annoying YML configuration files anymore. All we need to do is install SafeCommit via NPM and we can use it for all Swift projects, which is much more convenient than using the command line and embedding scripts in build phase as mentioned in the official README.
Another cost reduction is that we only lint files that have git add on them per commit. This has the advantage of not having large amounts of Lint causing slow commits every time, and also being more friendly to older projects that haven’t been lint before, so that minor changes don’t result in lots of warnings.
Standardization & universality
It is also much easier for teams to unify their code style thanks to the unified SafeCommit, which can be used across all Swift projects by simply configuring a single profile (out of the box for most teams, of course). SafeCommit is also not strongly dependent on other ides and can be used as long as your project is versioning through Git. Incidentally, due to SafeCommit’s universal design, it also supports Java CheckStyle, which can be extended if additional language support is required.
(v) Problems not solved by SafeCommit
For iOS development, there is no good way to achieve real-time performance of ESLint on VS Code, even the build phase of SwiftLint officially requires a build phase, so the awkward situation may have to wait for apple’s official Xcode feature.
(6) The meaning of brevity and standardization
Probably from the time to go to school can see the difference between people, their handwriting may not be good-looking but the pen must be neat, a stroke everywhere attentively. Originally neat writing and neat arrangement can not get two more points, but this rigorous craftsman attitude repeatedly let me admire.
Excellent is a habit, finally attached a manuscript of Einstein as the end, and you share my encouragement.
