All articles have been moved to my personal site: me.harley-xk.studio, please visit the comments

originally

Recently, I was doing Laravel back-end development with the company boss. I required to use PHP Lint for code specification check before pushing the code, so as to ensure that everyone could write the code with a uniform style, which was convenient for later maintenance and Review. Therefore, I began to reflect on the old line. Think of myself to write five or six years of iOS, although I think the code is very neat, but after writing high, I still ignore many details. Although it is harmless, but software development as an engineering nature of the east, always feel that standardization is a very important thing. Previous companies had implemented code specifications within the iOS group, but at that time it was more of a Word document, a list of specifications, and a meeting. Now that I’ve been exposed to a lot of other areas of development, I’m starting to see how important it is for developers to have a perspective on all aspects. Experience, ways of doing things and ideas in different fields can all be used for reference and integration. So I started looking at the possibility of implementing a similar solution on iOS. Coincidentally, I recently found SwiftLint while reading about iOS, so I decided to try it out.

SwiftLint is what?

SwiftLint is a cross-platform database for checking Swift code specifications from Realm, which is one of the most popular mobile apps in the world. SwiftLint is based on the Swift code specification published by Github for code checking and is well integrated with Xcode. After all the Settings are configured, SwiftLint automatically checks code when it is compiled in Xcode, and any code that does not conform to the specification will be indicated with warnings or errors. It also has a wealth of configuration items that can be customized, which is quite convenient.

Install the configuration

SwiftLint can be installed in a number of different ways, depending on your preference.

Install using Homebrew

Homebrew is a package management tool that comes with macOS and is easiest to install in this way:

brew install swiftlint
Copy the code
Install using CocoaPods

Installing via CocoaPods is also easy, just add dependencies to your Podfile:

pod 'SwiftLint'
Copy the code

This is then done automatically by executing Pod Install, which installs SwiftLint into the project’s Pods/ directory. This is a great solution if you want to use different versions of SwiftLint for different projects (Homebrew automatically installs the latest version).

Note that using this scheme will install the entire ** SwiftLint** and the entire resource files for its dependencies into the Pods/ directory, so be careful to ignore related directories when using a version management tool such as Git.

Using installation packages

SwiftLint also supports installation using the PKG installation package, which can be found on the official Github page.

Compile source code

SwiftLint is developed entirely using Swift and is open source under the MIT License, so you can download its source code and compile and install it using the following command:

git submodule update --init --recursive; make install
Copy the code
The installation is complete

After the installation is complete, enter swiftLint help to view all available commands:

➜  ~ swiftlint help
Available commands:

   autocorrect   Automatically correct warnings and errors
   help          Display general or command-specific help
   lint          Print lint warnings and errors (default command)
   rules         Display the list of rules and their identifiers
   version       Display the current version of SwiftLint
Copy the code

At this point, SwiftLint is installed

Configuring Xcode

You then need to configure the relevant compilation options in your project to make SwiftLint work in Xcode. The configuration is also simple. Create a New Run Script Phase configuration item in Xcode’s Build Phases and add the following code:

if which swiftlint >/dev/null; then
  swiftlint
else
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"
fi
Copy the code

As shown in the figure:

If you install SwiftLint through CocoaPods, replace SwiftLint with the path in CocoaPods: “${PODS_ROOT}/SwiftLint/ SwiftLint “. If SwiftLint is installed correctly, the code specification in SwiftLint will be checked. If SwiftLint is not installed, the script will throw a warning that SwiftLint is not installed and will prompt you to download. It is convenient to remind the team that there are no installed members in the team. Of course, you can also set it to force installation, in which case it will not compile if it is not installed. Just echo “Warning:…” in the script Then add a line of code: exit 1 so that if SwiftLint is not installed, compilation will throw a compilation error instead of a warning that SwiftLint needs to be installed. This configuration is complete, is not very simple.

Custom Configuration

Now compile the project to see if it is scary 😨 :

SwiftLint

To start, create a new configuration file named.swiftlint.yml in the root directory of the project and enter the following:

excluded: 
  - Pods
Copy the code

The excluded configuration is used to set the path where code specification checks can be ignored. It can be specified as a whole folder or as files in the exact path, listed below in the -xxxx format. For example, if your project uses Carthage to manage third-party libraries, You can add the Carthage directory to the ignore list:

excluded: 
  - Pods
  - Carthage
Copy the code

There are fewer compile errors, at least third party library compile errors are eliminated, oh yeah~

trailing_whitespace
SwiftLint

.swiftlint.yml 

disabled_rules:
  - trailing_whitespace
Copy the code

When you compile again and see that the trailing_whitespace problem is no longer prompted, you can configure to ignore specific rules in the same way.

Other rules

Xcode automatically generates code that often contains large sections of gaze, and we often choose to keep these comments. SwiftLint has a line_length rule, which checks the length of comments by default. You can set.swiftLint. Yml to ignore checking the length of comments:

line_length:
  warning: 110
  ignores_function_declarations: true
  ignores_comments: true
Copy the code

This code sets the line_length check rule: warning: 110 indicates that a warning will be raised if the number of characters in a line exceeds 110. You can set it to anything else. Ignores_function_declarations specifies whether to ignore the length of function definitions. Ignores_comments specifies whether to ignore the length of comments. Of course, you can also set the ignore single-line length rule in disabled_rules

There are all the rules that have been implemented so far. You can also implement your own rules and send them Pull requests.

I attached my own.swiftLint. yml file at the end of this article, and you can find more instructions on custom rules in the official SwiftLint documentation.

After all the configuration is set up, compile the code again, and then you can follow the error prompts to correct the non-standard code.

.swiftlint.ymlThe nested

.swiftlint.yml configuration files support nesting, therefore

  • You can specify different rule Settings for the code in each folder
  • Each file matches the configuration file in the parent folder closest to its hierarchy
  • In a nested configuration fileexcluded 和 includedThe configuration is ignored

##### Conclusion: I have finally finished my first technical blog. I feel it is not easy to write articles. I hope to keep it up. This article was written after I did some preliminary research on SwiftLint, there must be a lot of fallacies and inadequacies, please spray

.swiftlint.yml

disabled_rules: # rule identifiers to exclude from running
  - force_cast
  - trailing_whitespace
  - cyclomatic_complexity
  - unused_closure_parameter
# - colon
# - comma
# - control_statement
# opt_in_rules: # some rules are only opt-in
# - empty_count
# - missing_docs
# # Find all the available rules by running:
# # swiftlint rules
# included: # paths to include during linting. `--path` is ignored if present.
# - Docs.M/*/*.swift
excluded: # paths to ignore during linting. Takes precedence over `included`.
  - Carthage
  - Pods
  # - Source/ExcludedFolder
  # - Source/ExcludedFile.swift

# configurable rules can be customized from this configuration file
# binary rules can set their severity level
# force_cast: warning # implicitly
force_try:
  severity: warning # explicitly
# rules that have both warning and error levels, can set just the warning level
# implicitly
line_length:
  warning: 200
  ignores_function_declarations: true
  ignores_comments: true

# they can set both implicitly with an array
type_body_length:
  - 300 # warning- 400.# error
# or they can set both explicitly
file_length:
  warning: 500
  error: 1200
# naming rules can set warnings/errors for min_length and max_length
# additionally they can set excluded names
# type_name:
# min_length: 4 # only warning
# max_length: # warning and error
# warning: 40
# error: 50
# excluded: iPhone # excluded via string
identifier_name:
  min_length: # only min_length
    error: 3 # only error
  excluded: # excluded via string array
    - id
# - URL
# - GlobalAPIKey
reporter: "xcode" # reporter type (xcode, json, csv, checkstyle, junit, html, emoji)
Copy the code