// 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.

// 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.

// 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

Configuration

• disabled_rules: Disable rules from the default enabled set.
• opt_in_rules: Enable rules that are not part of the default set. The special all identifier will enable all opt in linter rules, except the ones listed in disabled_rules.
• only_rules: Only the rules specified in this list will be enabled. Cannot be specified alongside disabled_rules or opt_in_rules.
• analyzer_rules: This is an entirely separate list of rules that are only run by the analyze command. All analyzer rules are opt-in, so this is the only configurable rule list, there are no equivalents for disabled_rules and only_rules. The special all identifier can also be used here to enable all analyzer rules, except the ones listed in disabled_rules. ` # By default, SwiftLint uses a set of sensible default rules you can adjust. Find all the available rules # by running `swiftlint rules` or visiting https://realm.github.io/SwiftLint/rule-directory.html.

Rules turned on by default can be disabled.

Alternatively, specify all rules explicitly by uncommenting this option and removing the above two.

only_rules:

- empty_parameters

- vertical_whitespace

Rules only run by `swiftlint analyze`. These are all opt-in.

Case-sensitive paths to include during linting. Directory paths supplied on the

command line will be ignored. Wildcards are supported.

Case-sensitive paths to ignore during linting. Takes precedence over `included`. Wildcards

are supported.

If true, SwiftLint will not fail if no lintable files are found.

If true, SwiftLint will treat all warnings as errors.

If true, SwiftLint will treat all errors as warnings.

The path to a baseline file, which will be used to filter out detected violations.

The path to save detected violations to as a new baseline.

If true, SwiftLint will check for updates after linting or analyzing.

Configurable rules can be customized. All rules support setting their severity level.

To set both levels implicitly, use an array.

To set both levels explicitly, use a dictionary.

set excluded names and allowed symbols.

`emoji`, `github-actions-logging`, `gitlab`, `html`, `json`, `junit`, `markdown`, `relative-path`, `sarif`,

`sonarqube`, `summary`, or `xcode` (default).

You can also use environment variables in your configuration file, by using `${SOME_VARIABLE}` in a string.

### Defining Custom Rules

In addition to the rules that the main SwiftLint project ships with, SwiftLint can also run two types of custom rules that you can define yourself in your own projects:

#### 1\. Swift Custom Rules

These rules are written the same way as the Swift-based rules that ship with SwiftLint so they're fast, accurate, can leverage SwiftSyntax, can be unit tested, and more.

Using these requires building SwiftLint with Bazel as described in [this video](https://vimeo.com/820572803) or its associated code in [github.com/jpsim/swiftlint-bazel-example](https://github.com/jpsim/swiftlint-bazel-example).

#### 2\. Regex Custom Rules

You can define custom regex-based rules in your configuration file using the following syntax:

This is what the output would look like:

[![Custom violations highlighted in the Xcode editor](https://raw.githubusercontent.com/realm/SwiftLint/main/assets/custom-rule.png)](https://raw.githubusercontent.com/realm/SwiftLint/main/assets/custom-rule.png)

It is important to note that the regular expression pattern is used with the flags `s` and `m` enabled, that is `.` [matches newlines](https://developer.apple.com/documentation/foundation/nsregularexpression/options/1412529-dotmatcheslineseparators) and `^` / `$` [match the start and end of lines](https://developer.apple.com/documentation/foundation/nsregularexpression/options/1408263-anchorsmatchlines), respectively. If you do not want to have `.` match newlines, for example, the regex can be prepended by `(?-s)`.

You can filter the matches by providing one or more `match_kinds`, which will reject matches that include syntax kinds that are not present in this list. Here are all the possible syntax 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](https://github.com/jpsim/SourceKitten). For example, `sourcekitten syntax --text "struct S {}"` delivers

- `source.lang.swift.syntaxtype.keyword` for the `struct` keyword and
- `source.lang.swift.syntaxtype.identifier` for its name `S`

which match to `keyword` and `identifier` in the above list.

If using custom rules in combination with `only_rules`, you must include the literal string `custom_rules` in the `only_rules` list:

Unlike Swift custom rules, you can use official SwiftLint builds (e.g. from Homebrew) to run regex custom 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 `swiftlint --fix`, otherwise important data may be lost.

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 `swiftlint analyze` command can lint Swift files using the full type-checked AST. The compiler log path containing the clean `swiftc` build command invocation (incremental builds will fail) must be passed to `analyze` via the `--compiler-log-path` flag. e.g. `--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:

Project-Specific Configuration:

### Child/Parent Configs (Locally)

You can specify a `child_config` and/or a `parent_config` 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.

**A child config is treated as a refinement and thus 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:

To include both the refinement and the base file, your `.swiftlint.yml` should look like this:

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

Path merging follows these rules:

1. `included` / `excluded` entries from each config are resolved relative to that config file's directory.
2. Child entries override conflicting parent entries.
3. The merged path lists are computed as:

This means a child config can re-include a path excluded by its parent and can exclude a path included by its parent.

### Child/Parent Configs (Remote)

Just as you can provide local `child_config` / `parent_config` 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 `http://` or `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 `.swiftlint.yml` could look like this:

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 `remote_timeout` / `remote_timeout_if_cached` specifiers. These values default to 2 seconds or 1 second, respectively.

### 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

In addition to a main configuration (the `.swiftlint.yml` file in the root folder), you can put other configuration files named `.swiftlint.yml` into the directory structure. For a given file, SwiftLint walks up from that file's directory towards the root configuration and uses the first nested `.swiftlint.yml` it finds as a child config.

That nested config applies only to files in its directory subtree. Files in other subtrees continue using the main config (or their own nearest nested config).

Because SwiftLint stops at the first match while walking up the directory tree, **at most one nested configuration is merged per file** (in addition to the main configuration).

`.swiftlint.yml` files are only considered as a nested configuration if they have not been used to build the main configuration already (e. g. by having been referenced via something like `child_config: Folder/.swiftlint.yml`). Also, `parent_config` / `child_config` specifications of nested configurations are getting ignored because there's no sense to that.

If one (or more) SwiftLint file(s) are explicitly specified via the `--config` parameter, that configuration will be treated as an override, no matter whether there exist other `.swiftlint.yml` files somewhere within the directory. **So if you want to use nested configurations, you can't use the `--config` parameter.**

## License

[MIT licensed.](https://github.com/realm/SwiftLint/blob/main/LICENSE)

## About

SwiftLint is utterly maintained by volunteers contributing to its success entirely in their free time. As such, SwiftLint isn't a commercial product in any way.

Be kind to the people maintaining SwiftLint as a hobby and accept that their time is limited. Support them by contributing to the project, reporting issues, and helping others in the community.

Special thanks go to [MacStadium](https://www.macstadium.com/) for providing physical Mac mini machines to run our performance tests.

[![MacStadium](https://raw.githubusercontent.com/realm/SwiftLint/main/assets/macstadium.png)](https://raw.githubusercontent.com/realm/SwiftLint/main/assets/macstadium.png)

We also thank Realm (now MongoDB) for their initial contributions and setup of the project.