SwiftLint
0.57.0
Ein Werkzeug zur Durchsetzung des schnellen Stils und der Konventionen, die lose auf dem inzwischen archivierten Github Swift Style Guide basiert. SwiftLint setzt die Regeln für die Stilführer durch, die von der Swift -Community allgemein akzeptiert werden. Diese Regeln werden in populären Style -Führern wie dem Swift Style Guide von Kodeco gut beschrieben.
SwiftLint begleitet Clang und SourceKit, um die AST -Darstellung Ihrer Quelldateien für genauere Ergebnisse zu verwenden.
SwiftLint kann als Befehls -Plugin oder Build -Tool -Plugin verwendet werden.
Hinzufügen
. package ( url : " https://github.com/SimplyDanny/SwiftLintPlugins " , from : " <version> " ) in Ihrem Package.swift -Datei, um die neueste Version von SwiftLint automatisch zu konsumieren oder die Abhängigkeit in eine bestimmte Version zu stecken:
. package ( url : " https://github.com/SimplyDanny/SwiftLintPlugins " , exact : " <version> " ) Ersetzen Sie <version> durch das gewünschte Minimum oder die genaue Version.
Notiz
Das Verbrauch der Plugins direkt aus dem SwiftLint -Repository ist mit mehreren Nachteilen. Um sie zu vermeiden und den auferlegten Overhead zu verringern, wird dringend empfohlen, die Plugins aus dem dedizierten SwiftLintplugins -Repository zu konsumieren, obwohl Plugins aus dem SwiftLint -Repository ebenfalls absolut funktional sind. Wenn die Plugins von SwiftLint bevorzugt werden, verwenden Sie einfach die URL https://github.com/realm/SwiftLint in den obigen Paketdeklarationen.
SwiftLintplugins erleichtert jedoch die Einführung von Plugin massiv. Es listet einige der Gründe auf, aus denen die Plugins von Swiftlint selbst sehr problematisch vorgestellt werden. Da der Plugin -Code und die Veröffentlichungen synchronisiert werden, gibt es keinen Unterschied in der Funktionalität zwischen den beiden, aber Sie ersparen sich viel Zeit und Probleme mit dem dedizierten Plugins -Repository.
In diesem Dokument geht davon aus, dass Sie sich auf SwiftLintplugins verlassen.
Verwenden Sie den folgenden Link, um SwiftLint als Paketabhängigkeit zu einem Xcode -Projekt hinzuzufügen:
https://github.com/SimplyDanny/SwiftLintPluginsbrew install swiftlint Fügen Sie Ihrem Podfile Folgendes hinzu:
pod 'SwiftLint' Dadurch wird die SwiftLint -Binärdateien und -Epparien in Pods/ während Ihrer nächsten pod install heruntergeladen und ermöglicht es Ihnen, sie über ${PODS_ROOT}/SwiftLint/swiftlint in Ihren Skript -Build -Phasen aufzurufen.
Durch die Installation über Cocoapods können Sie auch an eine bestimmte Version von SwiftLint anstelle des neuesten (was bei Homebrew der Fall ist).
Beachten Sie, dass dies die SwiftLint -Binärdateien, die Binärdateien der Abhängigkeiten und die Verteilung der Swift -Binärbibliothek an die Pods/ Verzeichnisse hinzufügt. Wenn Sie also dieses Verzeichnis nach SCM wie Git überprüfen, werden Sie entmutigt.
mint install realm/SwiftLint Geben Sie dies in Ihr MODULE.bazel :
bazel_dep ( name = "swiftlint" , version = "0.52.4" , repo_name = "SwiftLint" ) Oder legen Sie dies in Ihren WORKSPACE :
load ( "@bazel_tools//tools/build_defs/repo:http.bzl" , "http_archive" )
http_archive (
name = "build_bazel_rules_apple" ,
sha256 = "390841dd5f8a85fc25776684f4793d56e21b098dfd7243cd145b9831e6ef8be6" ,
url = "https://github.com/bazelbuild/rules_apple/releases/download/2.4.1/rules_apple.2.4.1.tar.gz" ,
)
load (
"@build_bazel_rules_apple//apple:repositories.bzl" ,
"apple_rules_dependencies" ,
)
apple_rules_dependencies ()
load (
"@build_bazel_rules_swift//swift:repositories.bzl" ,
"swift_rules_dependencies" ,
)
swift_rules_dependencies ()
load (
"@build_bazel_rules_swift//swift:extras.bzl" ,
"swift_rules_extra_dependencies" ,
)
swift_rules_extra_dependencies ()
http_archive (
name = "SwiftLint" ,
sha256 = "c6ea58b9c72082cdc1ada4a2d48273ecc355896ed72204cedcc586b6ccb8aca6" ,
url = "https://github.com/realm/SwiftLint/releases/download/0.52.4/bazel.tar.gz" ,
)
load ( "@SwiftLint//bazel:repos.bzl" , "swiftlint_repos" )
swiftlint_repos ()
load ( "@SwiftLint//bazel:deps.bzl" , "swiftlint_deps" )
swiftlint_deps ()Dann können Sie SwiftLint im aktuellen Verzeichnis mit diesem Befehl ausführen:
bazel run -c opt @SwiftLint//:swiftlint Laden Sie SwiftLint.pkg von der neuesten GitHub -Version herunter und führen Sie es aus.
Stellen Sie sicher, dass das Build Tool Bazel und eine aktuelle Swift -Toolchain installiert sind und alle Tools in Ihrem PATH auffindbar sind.
Um SwiftLint zu erstellen, klonen Sie dieses Repository und führen Sie make install durch.
Wichtig
Während es intuitiv erscheint, SwiftLint auszuführen, bevor Swift -Quelldateien erfasst werden, um einen Build frühzeitig zu beenden, wenn FININT -Verstöße vorliegen, ist es wichtig zu verstehen, dass SwiftLint so konzipiert ist, dass es den gültigen Quellcode analysiert, der kompiliert werden kann. Nicht-Kompiliercode kann sehr leicht zu unerwarteten und verwirrenden Ergebnissen führen, insbesondere bei der Ausführung mit --fix / --autocorrect -Befehlszeilenargumenten.
SwiftLint kann als Build -Tool -Plugin für Swift -Paketprojekte und Xcode -Projekte verwendet werden.
Das Build -Tool -Plugin bestimmt das SwiftLint -Arbeitsverzeichnis, indem die oberste Konfigurationsdatei im Verzeichnis für Paket/Projekt aufgeführt ist. Wenn eine Konfigurationsdatei nicht gefunden wird, wird das Paket-/Projektverzeichnis als Arbeitsverzeichnis verwendet.
Das Plugin macht einen Fehler, wenn es das SwiftLint -Arbeitsverzeichnis nicht beheben kann. Dies erfolgt beispielsweise in Xcode -Projekten, bei denen sich die Swift -Dateien des Ziels nicht im Projektverzeichnis befinden.
Um die Kompatibilität mit dem Plugin zu maximieren, vermeiden Sie Projektstrukturen, die die Verwendung der Option --config erfordern.
Notiz
Erfordert eine Installation über Swift Package Manager.
Bauen Sie Tool -Plugins aus, wenn Sie jedes Ziel erstellen. Wenn ein Projekt mehrere Ziele hat, muss das Plugin den gewünschten Zielen einzeln hinzugefügt werden.
Fügen Sie dazu das Plugin zu den Zielen hinzu, um wie folgt abgegeben zu werden:
. target (
...
plugins : [ . plugin ( name : " SwiftLintBuildToolPlugin " , package : " SwiftLintPlugins " ) ]
) ,Notiz
Erfordert eine Installation über Swift Package Manager.
Das Befehls -Plugin ermöglicht das Ausführen von Swiftlint aus der Befehlszeile wie folgt:
swift package plugin swiftlintNotiz
Erfordert die Installation über Xcode -Paketabhängigkeit.
Build -Tool -Plugins werden als Build -Phase jedes Ziels ausgeführt. Wenn ein Projekt mehrere Ziele hat, muss das Plugin den gewünschten Zielen einzeln hinzugefügt werden.
Fügen Sie dazu die SwiftLintBuildToolPlugin in die Phase der Run Build Tool Plug-ins hinzu, dass die Build Phases für die abgegebenen Ziele (en) abgegeben werden.
Tipp
Wenn Sie das Plugin zum ersten Mal verwenden, vertrauen Sie darauf und aktivieren Sie es, wenn Sie aufgefordert werden. Wenn ein Makros -Erbauwarnung vorhanden ist, wählen Sie es aus, um es zu vertrauen und auch die Makros zu aktivieren.
Für die unbeaufsichtigte Verwendung (z. B. auf CI) können Paket -Plugin- und Makrovalidierungen mit einem der folgenden Deaktivierungen deaktiviert werden:
Verwenden von xcodebuild -Optionen:
-skipPackagePluginValidation
-skipMacroValidationEinstellen von Xcode -Standardeinstellungen:
defaults write com.apple.dt.Xcode IDESkipPackagePluginFingerprintValidatation -bool YES
defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YESWichtig
Die unbeaufsichtigten Gebrauchsoptionen Bypass -Validierungsdialoge von Xcode und implizit alle Plugins und Makros vertrauen, was Sicherheitsauswirkungen hat.
Projektstrukturen, bei denen sich die Konfigurationsdatei von Swiftlint außerhalb des Paket-/Projektverzeichnisses befindet, werden nicht direkt vom Build -Tool -Plugin unterstützt. Dies liegt daran, dass es nicht möglich ist, Argumente zum Erstellen von Tool -Plugins zu übergeben (z. B. den Konfigurationsdateipfad).
Wenn Ihre Projektstruktur nicht direkt mit dem Build -Tool -Plugin funktioniert, sollten Sie eine der folgenden Optionen in Betracht ziehen:
parent_config: path/to/.swiftlint.yml , angegeben wird.Notiz
Basierend auf der verwendeten Installationsmethode kann die Shell -Befehlssyntax in der Phase des Ausführensskripts unterschiedlich sein oder eine zusätzliche Konfiguration erforderlich sein. Weitere Informationen finden Sie in den Installationsanweisungen.
Wenn das Build -Tool -Plugin nicht für Ihr Projekt -Setup funktioniert oder wenn zusätzliches benutzerdefiniertes Setup erforderlich ist, kann SwiftLint als Run -Skript -Erstellungsphase hinzugefügt werden. Dies ist nützlich, wenn sich ein Projekt -Setup auf der Option --config SwiftLint" verlässt. oder um alle Ziele in einem einzigen swiftlint -Aufruf zusammenzubringen. Dateieinschlüsse und Ausschlüsse können in der Konfiguration .swiftlint.yml konfiguriert werden.
Fügen Sie nach der Phase der Compile Sources ein benutzerdefiniertes Skript zu einer Run Script der Build Phases des primären App -Ziels hinzu. Verwenden Sie die folgende Skriptimplementierung:
if command -v swiftlint > /dev/null 2>&1
then
swiftlint
else
echo " warning: ` swiftlint ` command not found - See https://github.com/realm/SwiftLint#installation for installation instructions. "
fi Wenn Sie das SwiftLintplugin in einem Swift -Paket verwenden, können Sie sich auf die ausführbare swiftlint -Datei beziehen:
SWIFT_PACKAGE_DIR= " ${BUILD_DIR % Build /* } SourcePackages/artifacts "
SWIFTLINT_CMD= $( ls " $SWIFT_PACKAGE_DIR " /swiftlintplugins/SwiftLintBinary/SwiftLintBinary.artifactbundle/swiftlint- * /bin/swiftlint | head -n 1 )
if test -f " $SWIFTLINT_CMD " 2>&1
then
" $SWIFTLINT_CMD "
else
echo " warning: ` swiftlint ` command not found - See https://github.com/realm/SwiftLint#installation for installation instructions. "
fi Notiz
Der SWIFTLINT_CMD -Pfad verwendet die Standard -Xcode -Konfiguration und wurde auf Xcode 15/16 getestet. Bei einer anderen Konfiguration (z. B. einem benutzerdefinierten Swift -Paketpfad) passen Sie bitte die Werte entsprechend an.
Tipp
Deaktivieren Sie Based on dependency analysis um swiftlint für alle inkrementellen Builds auszuführen und die nicht spezifizierte Ausgänge zu unterdrücken.
Xcode 15 hat eine signifikante Änderung vorgenommen, indem der Standardwert der Build -Einstellung ENABLE_USER_SCRIPT_SANDBOXING von NO zu YES eingestellt wurde. Infolgedessen begegnet SwiftLint auf einen Fehler, der sich auf fehlende Dateiberechtigungen bezieht, die sich typischerweise als error: Sandbox: swiftlint(19427) deny(1) file-read-data.
Um dieses Problem zu beheben, muss die Einstellung ENABLE_USER_SCRIPT_SANDBOXING manuell festgelegt werden, um für das spezifische Ziel, für das SwiftLint konfiguriert wird, auf NO .
Wenn Sie Swiftlint über Homebrew auf Apple Silicon installiert haben, können Sie diese Warnung erleben:
warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint Das liegt daran, dass Homebrew on Apple Silicon die Binärdateien standardmäßig in den Ordner /opt/homebrew/bin eingebaut wird. Um Xcode zu unterweisen, wo SwiftLint zu finden ist, können Sie in Ihrer Build -Phase entweder in /opt/homebrew/bin zur PATH hinzufügen:
if [[ " $( uname -m ) " == arm64 ]]
then
export PATH= " /opt/homebrew/bin: $PATH "
fi
if command -v swiftlint > /dev/null 2>&1
then
swiftlint
else
echo " warning: ` swiftlint ` command not found - See https://github.com/realm/SwiftLint#installation for installation instructions. "
fi Oder Sie können einen symbolischen Link in /usr/local/bin erstellen, der auf die tatsächliche Binärdatei hinweist:
ln -s /opt/homebrew/bin/swiftlint /usr/local/bin/swiftlint Wenn Sie auch Verstöße reparieren möchten, kann Ihr Skript swiftlint --fix && swiftlint anstelle von swiftlint . Dies bedeutet, dass alle korrigierbaren Verstöße festgelegt werden, während sichergestellt wird, dass Warnungen in Ihrem Projekt wegen verbleibender Verstöße angezeigt werden.
Wenn Sie SwiftLint über Cocoapods installiert haben, sollte das Skript so aussehen:
" ${PODS_ROOT} /SwiftLint/swiftlint " Um SwiftLint in Visual Studio Code zu integrieren, installieren Sie die vscode-swiftlint Erweiterung vom Marktplatz.
Sie können die offizielle swiftlint Fastlane -Aktion verwenden, um SwiftLint als Teil Ihres Fastlane -Prozesses auszuführen.
swiftlint (
mode : :lint , # SwiftLint mode: :lint (default) or :autocorrect
executable : "Pods/SwiftLint/swiftlint" , # The SwiftLint binary path (optional). Important if you've installed it via CocoaPods
path : "/path/to/lint" , # Specify path to lint (optional)
output_file : "swiftlint.result.json" , # The path of the output file (optional)
reporter : "json" , # The custom reporter to use (optional)
config_file : ".swiftlint-ci.yml" , # The path of the configuration file (optional)
files : [ # List of files to process (optional)
"AppDelegate.swift" ,
"path/to/project/Model.swift"
] ,
ignore_exit_status : true , # Allow fastlane to continue even if SwiftLint returns a non-zero exit status (Default: false)
quiet : true , # Don't print status logs like 'Linting ' & 'Done linting' (Default: false)
strict : true # Fail on warnings? (Default: false)
) SwiftLint ist auch als Docker -Bild mit Ubuntu erhältlich. Wenn Sie also das erste Mal das Docker -Bild mit dem nächsten Befehl ziehen müssen:
docker pull ghcr.io/realm/swiftlint:latest Anschließend laufen Sie nur swiftlint in den Docker wie:
docker run -it -v ` pwd ` : ` pwd ` -w ` pwd ` ghcr.io/realm/swiftlint:latest Dadurch wird swiftlint im Ordner ausführen, in dem Sie sich gerade befinden ( pwd ), und zeigt eine Ausgabe wie:
$ docker run -it -v ` pwd ` : ` pwd ` -w ` pwd ` ghcr.io/realm/swiftlint:latest
Linting Swift files in current working directory
Linting ' RuleDocumentation.swift ' (1/490)
...
Linting ' YamlSwiftLintTests.swift ' (490/490)
Done linting ! Found 0 violations, 0 serious in 490 files.Hier haben Sie mehr Dokumentation über die Verwendung von Docker -Bildern.
$ swiftlint help
OVERVIEW: A tool to enforce Swift style and conventions.
USAGE: swiftlint <subcommand>
OPTIONS:
--version Show the version.
-h, --help Show help information.
SUBCOMMANDS:
analyze Run analysis rules
docs Open SwiftLint documentation website in the default web browser
generate-docs Generates markdown documentation for selected group of rules
lint (default) Print lint warnings and errors
baseline Operations on existing baselines
reporters Display the list of reporters and their identifiers
rules Display the list of rules and their identifiers
version Display the current version of SwiftLint
See 'swiftlint help <subcommand>' for detailed help. Führen Sie swiftlint im Verzeichnis mit den Swift -Dateien auf Lint aus. Verzeichnisse werden rekursiv durchsucht.
Um eine Liste von Dateien anzugeben, wenn Sie lint oder analyze verwenden (wie die Liste der von Xcode angegebenen Dateien, die vom ExtraBuildPhase Xcode -Plugin angegeben wurden, oder die Dateien im Arbeitsbaum basierend auf git ls-files -m ), können Sie dies durch Übergeben tun Die Option --use-script-input-files und Festlegen der folgenden Instanzvariablen: SCRIPT_INPUT_FILE_COUNT und SCRIPT_INPUT_FILE_0 , SCRIPT_INPUT_FILE_1 , ..., SCRIPT_INPUT_FILE_{SCRIPT_INPUT_FILE_COUNT - 1} . Similarly, files can be read from file lists by passing the option --use-script-input-file-lists and setting the following instance variables: SCRIPT_INPUT_FILE_LIST_COUNT and SCRIPT_INPUT_FILE_LIST_0 , SCRIPT_INPUT_FILE_LIST_1 , ..., SCRIPT_INPUT_FILE_LIST_{SCRIPT_INPUT_FILE_LIST_COUNT - 1} .
Dies sind die gleichen Umgebungsvariablen, die für Eingabedateien für benutzerdefinierte Xcode -Skriptphasen eingestellt sind.
Swiftlint haken sich in SourceKit, so dass es weiter funktioniert, während sich Swift entwickelt!
Dies hält auch SwiftLint schlank, da es nicht mit einem vollständigen Swift -Compiler versenden muss. Es kommuniziert nur mit dem offiziellen, den Sie bereits auf Ihrem Computer installiert haben.
Sie sollten SwiftLint immer mit derselben Toolchain ausführen, mit der Sie Ihren Code kompilieren.
Möglicherweise möchten Sie die Standard -Swift -Toolchain von SwiftLINT überschreiben, wenn mehrere Toolchains oder XCodes installiert sind.
Hier ist die Reihenfolge, in der Swiftlint bestimmt, welche Swift Toolchain verwendet werden soll:
$XCODE_DEFAULT_TOOLCHAIN_OVERRIDE$TOOLCHAIN_DIR oder $TOOLCHAINSxcrun -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 wird voraussichtlich in der usr/lib/ subditionorie des Werts gefunden, das in den oben genannten Pfaden übergeben wurde.
Sie können auch die TOOLCHAINS Umgebungsvariable auf die Reverse-DNS-Notation einstellen, die eine Swift-Toolchain-Version identifiziert:
TOOLCHAINS=com.apple.dt.toolchain.Swift_2_3 swiftlint --fix Unter Linux wird von SourceKit in /usr/lib/libsourcekitdInProc.so oder von der Umgebungsvariablen LINUX_SOURCEKIT_LIB_PATH angegeben oder angegeben.
pre-commit Haken Swiftlint kann als Vorkommit-Haken ausgeführt werden. Fügen Sie dies nach der Installation in das .pre-commit-config.yaml im Stammvermögen Ihres Repositorys hinzu:
repos :
- repo : https://github.com/realm/SwiftLint
rev : 0.50.3
hooks :
- id : swiftlint Passen Sie rev an die Swiftlint -Version Ihrer Wahl an. pre-commit autoupdate kann verwendet werden, um die aktuelle Version zu aktualisieren.
SwiftLint kann mithilfe von entry konfiguriert werden, um FERTUNGEN anzuwenden und bei Fehlern zu fehlen:
- repo : https://github.com/realm/SwiftLint
rev : 0.50.3
hooks :
- id : swiftlint
entry : swiftlint --fix --strict Über 200 Regeln sind in Swiftlint und der Swift -Community (das sind Sie!) In der Zeit weiterhin mehr im Laufe der Zeit bei. Anfragen werden gefördert.
Hier finden Sie eine aktualisierte Liste von Regeln und weitere Informationen dazu.
Sie können auch das Verzeichnis "Quelle/SwiftLintBuiltInRules/Rules" überprüfen, um ihre Implementierung anzuzeigen.
opt_in_rules sind standardmäßig deaktiviert (dh Sie müssen sie explizit in Ihrer Konfigurationsdatei aktivieren).
Richtlinien, wann eine Regel als Opt-In markiert werden soll:
empty_count )force_unwrapping )Regeln können mit einem Kommentar in einer Quelldatei mit dem folgenden Format deaktiviert werden:
// swiftlint:disable <rule1> [<rule2> <rule3>...]
Die Regeln werden bis zum Ende der Datei oder bis zum Linter einen Matching -Aktivierungs -Kommentar deaktiviert:
// swiftlint:enable <rule1> [<rule2> <rule3>...]
Zum Beispiel:
// 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 Durch das Inklusive des all Keywords werden alle Regeln deaktiviert, bis der Linter einen Matching -Aktivierungs -Kommentar sieht:
// swiftlint:disable all // swiftlint:enable all
Zum Beispiel:
// 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 Es ist auch möglich, einen Befehl disable oder enable indem Sie anhängen :previous :this oder :next , um den Befehl nur auf den vorherigen, dies (aktuellen) oder die nächste Zeile anzuwenden.
Zum Beispiel:
// 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 Führen Sie swiftlint rules aus, um eine Liste aller verfügbaren Regeln und ihrer Kennung zu drucken.
Konfigurieren Sie SwiftLint, indem Sie eine .swiftlint.yml -Datei aus dem Verzeichnis hinzufügen, von dem Sie SwiftLint ausführen. Die folgenden Parameter können konfiguriert werden:
Regeleinschluss:
disabled_rules : Deaktivieren Sie Regeln aus dem Standard -Aktivierungssatz.opt_in_rules : Aktivieren Sie Regeln, die nicht Teil des Standardsatzes sind. Das spezielle all -Identifier ermöglicht alle Optionen für Linter -Regeln, mit Ausnahme der in disabled_rules .only_rules : Nur die in dieser Liste angegebenen Regeln werden aktiviert. Kann nicht neben disabled_rules oder opt_in_rules angegeben werden.analyzer_rules : Dies ist eine völlig separate Liste von Regeln, die nur vom Befehl analyze ausgeführt werden. Alle Analysator-Regeln sind abgelehnt. Dies ist daher die einzige konfigurierbare Regelliste. Es gibt keine Äquivalente für disabled_rules und only_rules . Das spezielle all -Identifier kann auch hier verwendet werden, um alle Analysator -Regeln zu aktivieren, mit Ausnahme der in disabled_rules aufgeführten. # 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
# Case-sensitive paths to include during linting. Directory paths supplied on the
# command line will be ignored.
included :
- Sources
excluded : # case-sensitive paths to ignore during linting. Takes precedence over `included`
- Carthage
- Pods
- Sources/ExcludedFolder
- Sources/ExcludedFile.swift
- Sources/*/ExcludedFile.swift # exclude files with a wildcard
# If true, SwiftLint will not fail if no lintable files are found.
allow_zero_lintable_files : false
# If true, SwiftLint will treat all warnings as errors.
strict : false
# If true, SwiftLint will treat all errors as warnings.
lenient : false
# The path to a baseline file, which will be used to filter out detected violations.
baseline : Baseline.json
# The path to save detected violations to as a new baseline.
write_baseline : Baseline.json
# If true, SwiftLint will check for updates after linting or analyzing.
check_for_updates : true
# 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, summary) Sie können auch Umgebungsvariablen in Ihrer Konfigurationsdatei verwenden, indem Sie ${SOME_VARIABLE} in einer Zeichenfolge verwenden.
Zusätzlich zu den Regeln, mit denen das Haupt -SwiftLint -Projekt versendet wird, kann SwiftLint auch zwei Arten von benutzerdefinierten Regeln ausführen, die Sie in Ihren eigenen Projekten definieren können:
Diese Regeln sind genauso geschrieben wie die Swift-basierten Regeln, die mit SwiftLint versandt werden, sodass sie schnell, genau, Swiftsyntax nutzen können, können geprüft werden und vieles mehr.
Erfordert das Erstellen von SwiftLint mit Bazel, wie in diesem Video oder seinem zugehörigen Code in github.com/jpsim/swiftlint-bazel-plample beschrieben.
Sie können benutzerdefinierte regex-basierte Regeln in Ihrer Konfigurationsdatei mit der folgenden Syntax definieren:
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 : stringSo würde die Ausgabe aussehen:
Es ist wichtig zu beachten, dass das reguläre Expressionsmuster mit den fleißigen s und m verwendet wird . entspricht den Newlines und ^ / $ entspricht dem Start bzw. das Ende der Linien. Wenn Sie nicht haben wollen . Übereinstimmende Newlines, zum Beispiel kann der Regex nach (?-s) vorbereitet werden.
Sie können die Übereinstimmungen filtern, indem Sie ein oder mehrere match_kinds bereitstellen, die Übereinstimmungen ablehnen, die Syntaxsorten enthalten, die in dieser Liste nicht vorhanden sind. Hier sind alle möglichen Syntaxarten:
argumentattribute.builtinattribute.idbuildconfig.idbuildconfig.keywordcommentcomment.markcomment.urldoccommentdoccomment.fieldidentifierkeywordnumberobjectliteralparameterplaceholderstringstring_interpolation_anchortypeidentifier Alle Syntaxarten, die in einem Snippet aus Swift -Code verwendet werden, können extrahiert werden, in denen Sourcekitten gefragt wird. Zum Beispiel liefert sourcekitten syntax --text "struct S {}"
source.lang.swift.syntaxtype.keyword für das Struct -Keyword und für das struct -Keyword undsource.lang.swift.syntaxtype.identifier für seinen Namen S die in der obigen Liste mit keyword und identifier übereinstimmen.
Wenn Sie benutzerdefinierte Regeln in Kombination mit only_rules verwenden, müssen Sie die buchstäbliche Zeichenfolge custom_rules in die Liste der only_rules einbeziehen:
only_rules :
- custom_rules
custom_rules :
no_hiding_in_strings :
regex : " ([nN]inja) "
match_kinds : stringIm Gegensatz zu Swift -benutzerdefinierten Regeln können Sie offizielle SwiftLint -Builds (z. B. von Homebrew) verwenden, um die benutzerdefinierten Regeln für die Regex zu führen.
SwiftLint kann bestimmte Verstöße automatisch korrigieren. Dateien auf der Festplatte werden mit einer korrigierten Version überschrieben.
Bitte stellen Sie sicher, dass Sie Sicherungen dieser Dateien haben, bevor Sie swiftlint --fix ausführen, ansonsten können wichtige Daten verloren gehen.
Die Standardleistung ist bei der Korrektur deaktiviert, da die Wahrscheinlichkeit von Verstößen (oder deren Offsets) nach der Änderung einer Datei während der Anwendung von Korrekturen falsch ist.
Der Befehl swiftlint analyze kann Swift-Dateien mithilfe des vollständigen AST-Typ-Prüfungsstudiums vergeben. Der Compiler-Protokollpfad, der den Befehlsaufruf von Clean swiftc -Build enthält (inkrementelle Builds scheitern), muss über das Flag --compiler-log-path analyze werden. EG --compiler-log-path /path/to/xcodebuild.log
Dies kann durch erhalten werden durch
xcodebuild -workspace {WORKSPACE}.xcworkspace -scheme {SCHEME} > xcodebuild.logswiftlint analyze --compiler-log-path xcodebuild.logDie Analysatorregeln sind in der Regel erheblich langsamer als FINT -Regeln.
SwiftLint bietet eine Vielzahl von Möglichkeiten, um mehrere Konfigurationsdateien einzuschließen. Mehrere Konfigurationsdateien werden zu einer einzigen Konfiguration zusammengeführt, die dann so angewendet wird, wie eine einzige Konfigurationsdatei angewendet wird.
Es gibt eine Menge Anwendungsfälle, in denen die Verwendung mehrerer Konfigurationsdateien hilfreich sein kann:
Zum Beispiel könnte man eine teamweite gemeinsam genutzte Swiftlint-Konfiguration verwenden, während Überschreibungen in jedem Projekt über eine untergeordnete Konfigurationsdatei zugelassen werden.
Teamweite Konfiguration:
disabled_rules :
- force_castProjektspezifische Konfiguration:
opt_in_rules :
- force_cast In einer Konfigurationsdatei können Sie eine child_config und/oder eine parent_config -Referenz angeben. Diese Referenzen sollten lokale Pfade im Verhältnis zum Ordner der Konfigurationsdatei sein, in denen sie angegeben sind. Dies funktioniert sogar rekursiv, solange es keine Zyklen und keine Unklarheiten gibt.
Eine untergeordnete Konfiguration wird als Verfeinerung behandelt und hat somit eine höhere Priorität , während eine übergeordnete Konfiguration bei Konflikten als Basis mit niedrigerer Priorität angesehen wird.
Hier ist ein Beispiel unter der Annahme, dass Sie die folgende Dateistruktur haben:
ProjectRoot
|_ .swiftlint.yml
|_ .swiftlint_refinement.yml
|_ Base
|_ .swiftlint_base.yml Um sowohl die Verfeinerung als auch die Basisdatei einzubeziehen, sollte Ihr .swiftlint.yml so aussehen:
child_config : .swiftlint_refinement.yml
parent_config : Base/.swiftlint_base.yml Bei der Zusammenführung von included und excluded Konfigurationen werden Konfigurationen sorgfältig verarbeitet, um Unterschiede im Verzeichnisort der enthaltenden Konfigurationsdateien zu berücksichtigen.
So wie Sie lokale Referenzen child_config / parent_config angeben können, können Sie nur URLs einsetzen, die zu Konfigurationsdateien führen. Damit SwiftLint diese Remote -Referenzen erfasst, müssen sie mit http:// oder https:// beginnen.
Die referenzierten Remote -Konfigurationsdateien können möglicherweise sogar auf andere Remote -Konfigurationsdateien referenzieren, dürfen jedoch nicht lokale Referenzen einbeziehen.
Mit einer Remote -Referenz könnte Ihr .swiftlint.yml so aussehen:
parent_config : https://myteamserver.com/our-base-swiftlint-config.ymlJedes Mal, wenn Sie SwiftLint ausführen und eine Internetverbindung haben, versucht Swiftlint, eine neue Version jeder referenzierten Remote -Konfiguration zu erhalten. Wenn diese Anfrage ausfällt, wird eine zwischengespeicherte Version verwendet, sofern verfügbar. Wenn keine zwischengespeicherte Version verfügbar ist, schlägt SwiftLint fehl - aber keine Sorgen, eine zwischengespeicherte Version sollte vorhanden sein, sobald Swiftlint mindestens einmal erfolgreich ausgeführt hat.
Bei Bedarf können die Timeouts für das Remote -Konfigurationsfetching über die Konfigurationsdatei (n) unter Verwendung der Angaben remote_timeout / remote_timeout_if_cached manuell angegeben werden. Diese Werte standardmäßig 2 Sekunden bzw. 1 Sekunde.
Anstatt nur eine Konfigurationsdatei bereitzustellen, wenn Sie SwiftLint über die Befehlszeile ausgeführt haben, können Sie auch eine Hierarchie übergeben, in der die erste Konfiguration als Elternteil behandelt wird, während die letzte als das Kind mit höchster Priorität behandelt wird.
Ein einfaches Beispiel mit nur zwei Konfigurationsdateien sieht folgt aus:
swiftlint --config .swiftlint.yml --config .swiftlint_child.yml
Zusätzlich zu einer Hauptkonfiguration (die Datei .swiftlint.yml im Stammordner) können Sie andere Konfigurationsdateien mit dem Namen .swiftlint.yml in die Verzeichnisstruktur einfügen, die dann als untergeordnete Konfiguration verschmelzen, jedoch nur mit einem Effekt für diese Dateien, die sich in demselben Verzeichnis wie die Konfiguration oder in einem tieferen Verzeichnis befinden, in dem es keine andere Konfigurationsdatei gibt. Mit anderen Worten: verschachtelte Konfigurationen funktionieren nicht rekursiv - es gibt eine maximale Anzahl einer verschachtelten Konfiguration pro Datei, die zusätzlich zur Hauptkonfiguration angewendet werden kann.
.swiftlint.yml -Dateien werden nur als verschachtelte Konfiguration angesehen, wenn sie nicht zur Erstellung der Hauptkonfiguration verwendet wurden (z. B. durch Referenz über etwas wie child_config: Folder/.swiftlint.yml ). Außerdem werden parent_config / child_config Spezifikationen verschachtelter Konfigurationen ignoriert, da dies keinen Sinn gibt.
Wenn eine (oder mehr) SwiftLint -Datei (n) über den Parameter --config explizit angegeben wird, wird diese Konfiguration als Überschreibung behandelt, unabhängig davon, ob andere .swiftlint.yml -Dateien irgendwo innerhalb des Verzeichnisses vorhanden sind. Wenn Sie also verschachtelte Konfigurationen verwenden möchten, können Sie den Parameter --config nicht verwenden.
MIT lizenziert.
SwiftLint wird von Realm Inc. gepflegt und finanziert. Die Namen und Logos für Realm sind Marken von Realm Inc.
Wir ❤️ Open Source -Software! Sehen Sie sich unsere anderen Open -Source -Projekte an, lesen Sie unseren Blog oder sagen Sie Hallo auf Twitter (@realm).
Wir danken Macstadium für die Bereitstellung eines Mac Mini, um unsere Leistungstests durchzuführen.
