これらは、カスタムXcodeスクリプトフェーズへの入力ファイルに設定されたのと同じ環境変数です。

複数の Swift バージョンでの作業

SwiftLint は SourceKit にフックするので、Swift が進化しても動作し続けます!

これにより、SwiftLintは完全なSwiftで出荷する必要がないため、無駄のない状態に保たれます。 コンパイラ、それはあなたがすでにインストールした公式のものと通信するだけです あなたのマシンで。

SwiftLintは、コンパイルに使用するのと同じツールチェーンで常に実行する必要があります。 コード。

次の場合は、SwiftLintのデフォルトのSwiftツールチェーンをオーバーライドすることをお勧めします。 複数のツールチェーンまたはXコードがインストールされています。

SwiftLint が使用する Swift ツールチェーンを決定する順序は次のとおりです。

• $XCODE_DEFAULT_TOOLCHAIN_OVERRIDE

• $TOOLCHAIN_DIR

  又は

  $TOOLCHAINS

• xcrun -find swift

• /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

• /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

• ~/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

• ~/Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

sourcekitd.framework

usr/lib/

環境変数を逆引きDNSに設定することもできます Swiftツールチェーンのバージョンを識別する表記:

TOOLCHAINS

$ TOOLCHAINS=com.apple.dt.toolchain.Swift_2_3 swiftlint --fix

Linux では、SourceKit は環境変数に配置されるか、環境変数によって指定されることが想定されます。

/usr/lib/libsourcekitdInProc.so

LINUX_SOURCEKIT_LIB_PATH

事前コミット

SwiftLint はコミット前のフックとして実行できます。 インストールしたら、これをリポジトリのルートに追加します。

.pre-commit-config.yaml

repos:
  - repo: https://github.com/realm/SwiftLint
    rev: 0.50.3
    hooks:
      - id: swiftlint

選択したスウィフトリントバージョンに調整します。 現在のバージョンに更新するために使用できます。

rev

pre-commit autoupdate

SwiftLintは、修正を適用し、エラーで失敗するように構成できます。

entry

-   repo: https://github.com/realm/SwiftLint
    rev: 0.50.3
    hooks:
    -   id: swiftlint
        entry: swiftlint --fix --strict

準則

200以上のルールがSwiftLintとSwiftコミュニティに含まれています(それはあなたです! 時間の経過とともにより多くの貢献を続けています。プル要求が推奨されます。

更新されたルールのリストとその詳細については、こちらを参照してください。

また、Source/SwiftLintFramework/Rules ディレクトリをチェックして、その実装を確認することもできます。

オプトインルール

opt_in_rules

ルールをオプトインとしてマークするタイミングに関するガイドライン:

• 多くの誤検知を持つ可能性のあるルール (例:

  empty_count

  )
• ルールが遅すぎる
• 一般的なコンセンサスではない、または一部の場合にのみ役立つルール (例えば、

  force_unwrapping

  )

コードで規則を無効にする

ルールは、ソースファイル内のコメントで無効にできます。 形式：

// swiftlint:disable <rule1> [<rule2> <rule3>...]

ルールは、ファイルの最後まで、またはリンターが マッチング有効コメント:

// swiftlint:enable <rule1> [<rule2> <rule3>...]

例えば：

// swiftlint:disable colon
let noWarning :String = "" // No warning about colons immediately after variable names!
// swiftlint:enable colon
let hasWarning :String = "" // Warning generated about colons immediately after variable names

キーワードを含めると、リンターに一致する有効コメントが表示されるまで、すべてのルールが無効になります。

all

// swiftlint:disable all

// swiftlint:enable all

例えば：

// swiftlint:disable all
let noWarning :String = "" // No warning about colons immediately after variable names!
let i = "" // Also no warning about short identifier names
// swiftlint:enable all
let hasWarning :String = "" // Warning generated about colons immediately after variable names
let y = "" // Warning generated about short identifier names

また、 または コマンドを 、または前のコマンドにのみ適用して、 この(現在の)行または次の行。

disable

enable

:previous

:this

:next

例えば：

// swiftlint:disable:next force_cast
let noWarning = NSNumber() as! Int
let hasWarning = NSNumber() as! Int
let noWarning2 = NSNumber() as! Int // swiftlint:disable:this force_cast
let noWarning3 = NSNumber() as! Int
// swiftlint:disable:previous force_cast

実行して、使用可能なすべてのルールとそのルールのリストを印刷します 識別子。

swiftlint rules

構成

SwiftLintを構成するには、ディレクトリからファイルを追加します からスウィフトリントを実行します。次のパラメータを設定できます。

.swiftlint.yml

ルールの包含:

• disabled_rules

  : デフォルトの有効セットからルールを無効にします。

• opt_in_rules

  : デフォルトセットの一部ではないルールを有効にします。

• only_rules

  : このリストで指定されたルールのみが有効になります。 または と一緒に指定することはできません。

  disabled_rules

  opt_in_rules

• analyzer_rules

  :これは、 コマンドによって実行されます。すべてのアナライザールールはオプトインであるため、これは 構成可能なルール リストのみで、 に相当するものはありません。

  analyze

  disabled_rules

  only_rules

# By default, SwiftLint uses a set of sensible default rules you can adjust:
disabled_rules: # rule identifiers turned on by default to exclude from running
  - colon
  - comma
  - control_statement
opt_in_rules: # some rules are turned off by default, so you need to opt-in
  - empty_count # Find all the available rules by running: `swiftlint rules`

# Alternatively, specify all rules explicitly by uncommenting this option:
# only_rules: # delete `disabled_rules` & `opt_in_rules` if using this
#   - empty_parameters
#   - vertical_whitespace

analyzer_rules: # Rules run by `swiftlint analyze`
  - explicit_self

included: # paths to include during linting. `--path` is ignored if present.
  - Source
excluded: # paths to ignore during linting. Takes precedence over `included`.
  - Carthage
  - Pods
  - Source/ExcludedFolder
  - Source/ExcludedFile.swift
  - Source/*/ExcludedFile.swift # Exclude files with a wildcard

# If true, SwiftLint will not fail if no lintable files are found.
allow_zero_lintable_files: false

# 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: 110
# 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
  allowed_symbols: ["_"] # these are allowed in type names
identifier_name:
  min_length: # only min_length
    error: 4 # only error
  excluded: # excluded via string array
    - id
    - URL
    - GlobalAPIKey
reporter: "xcode" # reporter type (xcode, json, csv, checkstyle, codeclimate, junit, html, emoji, sonarqube, markdown, github-actions-logging)

構成ファイルで環境変数を使用することもできます。 文字列で使用します。

${SOME_VARIABLE}

カスタムルールの定義

構成ファイルでカスタム正規表現ベースのルールを定義するには、 次の構文:

custom_rules:
  pirates_beat_ninjas: # rule identifier
    included: 
      - ".*\\.swift" # regex that defines paths to include during linting. optional.
    excluded: 
      - ".*Test\\.swift" # regex that defines paths to exclude during linting. optional
    name: "Pirates Beat Ninjas" # rule name. optional.
    regex: "([nN]inja)" # matching pattern
    capture_group: 0 # number of regex capture group to highlight the rule violation at. optional.
    match_kinds: # SyntaxKinds to match. optional.
      - comment
      - identifier
    message: "Pirates are better than ninjas." # violation message. optional.
    severity: error # violation severity. optional.
  no_hiding_in_strings:
    regex: "([nN]inja)"
    match_kinds: string

This is what the output would look like:

You can filter the matches by providing one or more , which will reject matches that include syntax kinds that are not present in this list. Here are all the possible syntax kinds:

match_kinds

• argument

• attribute.builtin

• attribute.id

• buildconfig.id

• buildconfig.keyword

• comment

• comment.mark

• comment.url

• doccomment

• doccomment.field

• identifier

• keyword

• number

• objectliteral

• parameter

• placeholder

• string

• string_interpolation_anchor

• typeidentifier

All syntax kinds used in a snippet of Swift code can be extracted asking SourceKitten. For example, delivers

sourcekitten syntax --text "struct S {}"

• source.lang.swift.syntaxtype.keyword

  for the keyword and

  struct

• source.lang.swift.syntaxtype.identifier

  for its name

  S

which match to and in the above list.

keyword

identifier

If using custom rules in combination with , make sure to add as an item under .

only_rules

custom_rules

only_rules

Auto-correct

SwiftLint can automatically correct certain violations. Files on disk are overwritten with a corrected version.

Please make sure to have backups of these files before running , otherwise important data may be lost.

swiftlint --fix

Standard linting is disabled while correcting because of the high likelihood of violations (or their offsets) being incorrect after modifying a file while applying corrections.

Analyze

The command can lint Swift files using the full type-checked AST. The compiler log path containing the clean build command invocation (incremental builds will fail) must be passed to via the flag. e.g.

swiftlint analyze

swiftc

analyze

--compiler-log-path

--compiler-log-path /path/to/xcodebuild.log

This can be obtained by

1. Cleaning DerivedData (incremental builds won't work with analyze)
2. Running

   xcodebuild -workspace {WORKSPACE}.xcworkspace -scheme {SCHEME} > xcodebuild.log

3. Running

   swiftlint analyze --compiler-log-path xcodebuild.log

Analyzer rules tend to be considerably slower than lint rules.

Using Multiple Configuration Files

SwiftLint offers a variety of ways to include multiple configuration files. Multiple configuration files get merged into one single configuration that is then applied just as a single configuration file would get applied.

There are quite a lot of use cases where using multiple configuration files could be helpful:

For instance, one could use a team-wide shared SwiftLint configuration while allowing overrides in each project via a child configuration file.

Team-Wide Configuration:

disabled_rules:
- force_cast

Project-Specific Configuration:

opt_in_rules:
- force_cast

Child / Parent Configs (Locally)

You can specify a and / or a reference within a configuration file. These references should be local paths relative to the folder of the configuration file they are specified in. This even works recursively, as long as there are no cycles and no ambiguities.

child_config

parent_config

A child config is treated as a refinement and therefore has a higher priority, while a parent config is considered a base with lower priority in case of conflicts.

Here's an example, assuming you have the following file structure:

ProjectRoot
    |_ .swiftlint.yml
    |_ .swiftlint_refinement.yml
    |_ Base
        |_ .swiftlint_base.yml

To include both the refinement and the base file, your should look like this:

.swiftlint.yml

child_config: .swiftlint_refinement.yml
parent_config: Base/.swiftlint_base.yml

When merging parent and child configs, and configurations are processed carefully to account for differences in the directory location of the containing configuration files.

included

excluded

Child / Parent Configs (Remote)

Just as you can provide local / references, instead of referencing local paths, you can just put urls that lead to configuration files. In order for SwiftLint to detect these remote references, they must start with or .

child_config

parent_config

http://

https://

The referenced remote configuration files may even recursively reference other remote configuration files, but aren't allowed to include local references.

Using a remote reference, your could look like this:

.swiftlint.yml

parent_config: https://myteamserver.com/our-base-swiftlint-config.yml

Every time you run SwiftLint and have an Internet connection, SwiftLint tries to get a new version of every remote configuration that is referenced. If this request times out, a cached version is used if available. If there is no cached version available, SwiftLint fails – but no worries, a cached version should be there once SwiftLint has run successfully at least once.

If needed, the timeouts for the remote configuration fetching can be specified manually via the configuration file(s) using the / specifiers. These values default to 2 / 1 second(s).

remote_timeout

remote_timeout_if_cached

Command Line

Instead of just providing one configuration file when running SwiftLint via the command line, you can also pass a hierarchy, where the first configuration is treated as a parent, while the last one is treated as the highest-priority child.

A simple example including just two configuration files looks like this:

swiftlint --config .swiftlint.yml --config .swiftlint_child.yml

Nested Configurations

メイン設定(ルートフォルダ内のファイル)に加えて、 という名前の他の構成ファイルをディレクトリ構造に入れることができます その後、子構成としてマージされますが、それらのファイルに対してのみ効果があります 構成と同じディレクトリ内、またはより深いディレクトリにあります。 別の構成ファイルはありません。つまり、ネストされた構成は機能しません 再帰的 – ファイルごとに最大数が 1 つのネストされた構成です )は、主構成に加えて適用してもよい。

.swiftlint.yml

.swiftlint.yml

.swiftlint.yml

child_config: Folder/.swiftlint.yml

parent_config

child_config

1つ(または複数)のSwiftLintファイルがパラメータを介して明示的に指定されている場合、 その構成は、存在するかどうかに関係なく、オーバーライドとして扱われます ディレクトリ内のどこかにある他のファイル。したがって、使用したい場合は 入れ子になった構成では、--config パラメーターを使用できません。

--config

.swiftlint.yml