SwiftLint - Sauberkeit und Ordnung im iOS-Projekt

    Bild

    Ich denke , jeder weiß , wie es schwierig ist , die Einhaltung des Code - Stil zu halten und Vereinbarungen in dem iOS-Projekt. Heute werden wir darüber sprechen, wie dieser Prozess mit dem Dienstprogramm SwiftLint automatisiert werden kann.

    SwiftLint ist ein Dienstprogramm von Realm-Entwicklern zur automatischen Überprüfung von Swift-Code. Das Dienstprogramm enthält eine Reihe von Regeln, die auf GitHubs Swift Style Guide und dem gesunden Menschenverstand basieren . Natürlich können Sie Ihre eigenen Regeln hinzufügen. SwiftLint unterstützt die Integration mit Xcode, Appcode, Atom.

    Installation und Konfiguration
    Laden Sie die neueste Version aus dem Repository herunter und installieren Sie sie .

    Oder über das Terminal installieren:

    $ brew update
    $ brew install swiftlint

    Sie können das Dienstprogramm folgendermaßen aktualisieren:

    $ brew update
    $ brew upgrade swiftlint

    Wechseln Sie zu einer anderen Version:

    $ brew switch swiftlint <номер версии>

    Finden Sie die aktuelle Version heraus:

    swiftlint version

    Wir gehen in die Projekteinstellungen, erstellen Phasen und fügen dem Abschnitt "Skript ausführen" Folgendes hinzu:

    if which swiftlint >/dev/null; then
      swiftlint
    else
      echo "error: SwiftLint does not exist, download it from https://github.com/realm/SwiftLint"
      exit 1
    fi

    Tipp: Es wird dringend empfohlen, den Befehl "exit 1" zu verwenden. Dadurch wird sichergestellt, dass alle Mitglieder des Teams SwiftLint installieren.

    Erster
    Start Nach der Installation von SwiftLint wird der Code am Ende jeder Projekterstellung überprüft. Nach dem ersten Start werden Sie höchstwahrscheinlich Folgendes sehen:



    Machen Sie sich keine Sorgen, die meisten Fehler und Warnungen sind recht einfach und leicht zu beheben. Beeilen Sie sich nicht, um sie manuell zu reparieren, da SwiftLint eine wunderbare Autokorrekturfunktion hat, ist es ziemlich sicher. Um es im Terminal zu verwenden, rufen Sie das Projektverzeichnis auf und führen Sie den folgenden Befehl aus:

    swiftlint autocorrect

    Wir montieren das Projekt erneut: Die Anzahl der Fehler wurde um ein Vielfaches reduziert, die verbleibenden müssen jedoch manuell korrigiert werden.
    Tipp: Fügen Sie Run Script keine automatische Korrektur hinzu, da sich Programmierer sonst daran gewöhnen, einige Konventionen nicht zu beachten oder gar nicht zu kennen.

    Regeln
    Eine Liste der vordefinierten Regeln kann durch Ausführen des Befehls angezeigt werden:

    swiftlint rules



    Jede Regel hat eine Beschreibung und eine Reihe von Parametern:

    • Opt-in - ob die Regel optional ist (standardmäßig deaktiviert);
    • korrigierbar - Ist es möglich, die Regel zu konfigurieren?
    • aktiviert in Ihrer Konfiguration - ob es im Projekt aktiviert ist;
    • Konfiguration - Parameter.

    Zum besseren Verständnis können Sie auch den Quellcode der Regeln sehen .

    Separat möchte ich einige sehr nützliche Regeln hervorheben:

    • сyclomatic_complexity - die Regel, die die zyklomatische Komplexität einschränkt ;
    • Verschachtelung - Verschachtelungsebene von Klassen und Funktionen;
    • file_length - die Anzahl der Zeilen in der Datei;
    • function_body_length - die Anzahl der Zeilen in der Funktion;
    • force_try / cast / unwrapping - Vorhandensein von Operationen, die möglicherweise zu einem Absturz führen;
    • weak_delegate - Überprüfen Sie, ob der Delegat eine schwache Referenz hat.
    • missing_docs - Gibt an, ob Kommentare zu öffentlichen Funktionen / Eigenschaften geschrieben werden.

    Konfiguration
    Höchstwahrscheinlich müssen Sie Regeln deaktivieren, konfigurieren oder hinzufügen. Erstellen Sie dazu eine .swiftlint.yml-Datei im Projektstamm.

    Verfügbare Konfigurationsoptionen:

    Liste der zu deaktivierenden Regeln:

    disabled_rules:
      - colon
      - comma
      - control_statement

    Liste der optionalen Regeln, die aktiviert werden müssen (standardmäßig deaktiviert):

    opt_in_rules:
      - empty_count
      - missing_docs

    Ausschließen von Unterverzeichnissen oder Dateien:

    excluded: 
      - Carthage
      - Pods
      - Source/ExcludedFolder
      - Source/ExcludedFile.swift

    Unterverzeichnisse oder Dateien einschließen (ausgeschlossene Alternative):

    included: 
      - MyProject
      - MyProjectKeyboard
      - MyProjectTests

    Regelparameter (verfügbare Parameter finden Sie in der Regelliste):

    file_length:
      warning: 500
      error: 600

    Berichtstyp (verfügbare Parameter: xcode, json, csv, checkstyle, junit):

    reporter: xcode

    Maximale Anzahl von Warnungen:

    warning_threshold: 15

    Tipp: Stellen Sie sicher, dass Sie der Konfigurationsdatei warning_threshold hinzufügen, damit die Anzahl der Warnungen nicht zunimmt.

    Verschachtelte Konfigurationen
    Sie können mehrere Konfigurationsdateien (.swiftlint.yml) für verschiedene Unterverzeichnisse erstellen. SwiftLint verwendet automatisch die Konfiguration, die sich im Ordner mit den gescannten Dateien befindet. Die ausgeschlossenen und eingeschlossenen Optionen für verschachtelte Konfigurationen werden ignoriert.

    Hinzufügen von
    benutzerdefinierten Regeln Mit SwiftLint können Sie benutzerdefinierte Regeln basierend auf regulären Ausdrücken hinzufügen. Fügen Sie dazu den Abschnitt custom_rules in die Datei .swiftlint.yml ein. Sie können die folgenden Parameter für eine Regel angeben:

    • Identifikator - Identifikator (erforderlich);
    • Regexp - Finding Condition (erforderlich);
    • name - der Name der Regel, die im Fehlertext angezeigt wird (optional);
    • Nachricht - Fehlerbeschreibung (erforderlich);
    • match_kinds - in welchen Entitäten nach einem Eintrag gesucht werden soll, verfügbare Werte (Sie können mehrere angeben): Kommentar, Kennung, Nummer, Parameter, Zeichenfolge, die vollständige Liste ist in der Dokumentation verfügbar (erforderlich);
    • Schweregrad - Typ: Warnung (Warnung) oder Fehler (Fehler) (optional, Standard ist Warnung);
    • enthalten - welche Dateien überprüft werden sollen (optional)

    Benennung der Regelprüfung mit dem Suffix -id. (zum Beispiel: userId - true, userID - wrong):

    custom_rules:
      id_suffix_naming:
        name: "Wrong name"
        regex: "(ID)"
        match_kinds:
          - comment
          - identifier
        message: "Use 'Id' instead 'ID'"
        severity: error



    Regeln im Code
    deaktivieren Wenn Sie die Regeln im Codeteil deaktivieren möchten, verwenden Sie die folgende Konstruktion:

    // swiftlint:disable  [...]
    .........
    // swiftlint:enable  [...]
    func printName() {
        // swiftlint:disable force_cast
        let name = loadName() as! String
        // swiftlint:enable force_cast
        print(name)
    }

    Geschwindigkeit
    der Projekterstellung Offensichtlich benötigt die Verwendung von SwiftLint zusätzliche Zeit für die Erstellung des Projekts. Wenn die Erstellungsgeschwindigkeit merklich nachlässt, sollten Sie nur die geänderten Dateien überprüfen. Ersetzen Sie dazu das Validierungsskript in Build-Phasen durch:

    Skript
    	
    count=0
    for file_path in $(git ls-files -om --exclude-from=.gitignore | grep ".swift$"); do
        export SCRIPT_INPUT_FILE_$count=$file_path
        count=$((count + 1))
    done
    for file_path in $(git diff --cached --name-only | grep ".swift$"); do
        export SCRIPT_INPUT_FILE_$count=$file_path
        count=$((count + 1))
    done
        export SCRIPT_INPUT_FILE_COUNT=$count
        swiftlint lint --use-script-input-files


    Einige Beispiele für SwiftLint-Konfigurationen bei namhaften Unternehmen:

    Kickstarter
    disabled_rules:
      - function_parameter_count
      - nesting
      - variable_name
      - weak_delegate
      - trailing_comma
    opt_in_rules:
      - empty_count
      - force_unwrapping
      - private_outlet
    line_length: 110
    type_body_length:
      warning: 300
      error: 400
    excluded:
      - Carthage/
      - Frameworks/
      - Kickstarter-iOS.playground/
      - Kickstarter-tvOS.playground/
      - Library/Strings.swift
      - bin/strings.swift
    reporter: "xcode"
    custom_rules:
      localized_lensing:
        name: "Localized Lensing"
        regex: "\.~\s+Strings\s*\."
        message: "Capture calls to `Strings` functions using `%~ { _ in Strings... }`"
        severity: error


    Firefox
    disabled_rules: # rule identifiers to exclude from running
      - legacy_constructor
      - variable_name
      - legacy_cggeometry_functions
      - legacy_constant
      - todo
      - trailing_newline
      - empty_count
      - force_cast
      - type_name
      - function_body_length
      - missing_docs
      - conditional_binding_cascade
      - valid_docs
      - cyclomatic_complexity
      - type_body_length
      - function_parameter_count
      - force_try
      - control_statement
      - trailing_whitespace
      - leading_whitespace
      - operator_whitespace
      - file_length
      - mark
    opt_in_rules: # some rules are only opt-in
      - closing_brace
      - opening_brace
      - return_arrow_whitespace
      - trailing_semicolon
      - statement_position
      # Find all the available rules by running:
      # swiftlint rules
    included: # paths to include during linting. `--path` is ignored if present.
    excluded: # paths to ignore during linting. Takes precedence over `included`.
      - Carthage
      - Pods
      - Source/ExcludedFolder
      - Source/ExcludedFile.swift
      - ThirdParty
      - FxA
      - FxAClient
      - build
    # configurable rules can be customized from this configuration file
    # binary rules can set their severity level
    trailing_semicolon: error
    empty_count: error
    closing_brace: error
    opening_brace: error
    return_arrow_whitespace: error
    statement_position: error
    colon: error
    comma: error
    line_length: 1000
    reporter: "json" # reporter type (xcode, json, csv, checkstyle)


    Reich
    
    included:
      - Realm/ObjectServerTests
      - RealmSwift
      - Realm/Swift
    variable_name:
      min_length: # not possible to disable this partial rule, so set it to zero
        warning: 0
        error: 0
    disabled_rules:
      - file_length
      - force_cast
      - force_try
      - function_body_length
      - todo
      - type_body_length
      - line_length
      - vertical_whitespace
      - syntactic_sugar


    Tinkoff
    warning_threshold: 15

    excluded:
    - Pods
    - MBUITest

    disabled_rules:
    - trailing_whitespace

    line_length:
    warning: 150

    function_parameter_count:
    warning: 10
    error: 15

    file_length:
    warning: 500

    type_body_length:
    warning: 400
    error: 450

    Mit SwiftLint konnte unser iOS-Entwicklungsteam weniger Zeit für Codeüberprüfungen aufwenden, sich an einen einzigen Codestil halten und die Codequalität verbessern. Wenn Sie SwiftLint noch nicht in Ihrem Projekt verwenden, probieren Sie es unbedingt aus.

    Nützliche Links:

    " Repository SwiftLint
    " Liste SwiftLint Regeln
    " Über - Scan nur Dateien , die sich geändert haben
    " GitHub Swift der Style Guide Review
    » Schneider - alternative SwiftLint

    Jetzt auch beliebt: