Get best of the week

Verwenden von SwiftLint Static Code Analyzer in iOS Mobile Banking-Anwendungen

Oleg Ivanov, Leiter des Kompetenzzentrums für Remote-Service-Kanäle



Hallo allerseits! Wie im Artikel „Mobile Banking von ICD: Geschichte der Entwicklung“ versprochen , möchte ich heute über statische Code-Analysatoren und die Erfahrung ihrer Anwendung in iOS-Mobilanwendungen der Bank sprechen.

Legen wir das Ziel fest, das wir mit diesem Toolkit erreichen möchten:

  • Früherkennung von Fehlern und Mängeln;
  • Code Style ( — , ).

Ein üblicher Weg, um unsere Ziele zu erreichen, ist die manuelle Überprüfung des Codes - Code Review .

Der Tester oder eine Gruppe von Testern prüft den zu testenden Code sorgfältig, identifiziert dann Fehler oder Abschnitte des Codes, die in Zukunft möglicherweise fehlerhaft werden, und gibt Empfehlungen zur Verbesserung durch Kommentare zum Code, die nach einiger Zeit (!) Vom Entwickler analysiert und korrigiert werden. Wie wir sehen können, entsteht ein langer und teurer Codeüberprüfungsprozess. Außerdem gibt es immer einen menschlichen Faktor - einige Fehler können von Rezensenten einfach übersprungen werden.

Hier helfen uns statische Code-Analysatoren.

Statische Code-Analysatoren- Starten Sie einen automatisierten Prozess zum Erkennen von Fehlern und Mängeln im Quellcode von Programmen.

Statische Code-Analysatoren sind kein Allheilmittel oder Ersatz für die manuelle Code-Überprüfung, aber sie sind ein hervorragendes Werkzeug, um die Zeit zu verkürzen, die für die Durchführung von Überprüfungen und das schnelle Auffinden von gemusterten Fehlern erforderlich ist. Die Relevanz der Verwendung statischer Analysegeräte wird mit der Zeit immer größer.

Als statischer Code-Analysator in unseren iOS-Projekten verwenden wir SwiftLint.

SwiftLint ist ein Dienstprogramm zur automatischen Überprüfung von Swift-Code, das während der Erstellungsphase eines Projekts ausgeführt wird. Das Dienstprogramm enthält eine Reihe von Regeln, mit denen Sie diese Reihe durch Ihre benutzerdefinierten Regeln ergänzen können. Das Tool wird auch verwendet, um den Codestil einzuhalten.

Warum ist es wichtig, Code Style in der Anwendung zu befolgen?
Wenn Sie ein Entwickler in einem Projekt sind, ist alles einfach: Sie schreiben in Ihrem eigenen Stil und können sich den Code folgendermaßen leisten:



Aber wenn Sie in einem großen Entwicklungsteam arbeiten. Ein wichtiger Faktor ist die Geschwindigkeit, mit der Sie verstehen und den Ort finden, an dem Verbesserungen in den Code eines anderen eingefügt werden können.
Und hier müssen alle Teammitglieder die Konventionen und Regeln für das Schreiben von Code akzeptieren. Aber wie kann man ihre Einhaltung überprüfen? Auch hier hilft uns der SwiftLint Static Code Analyzer. Und unser Code wird ein angenehmes Aussehen haben, das jedes Mitglied des Teams verstehen wird:



Um sich mit dem Tool vertraut zu machen, empfehle ich, die offizielle Dokumentation zu lesen .

Die Installation von SwiftLint ist einfach:

  1. Fügen Sie der Projekt-Poddatei den Pod 'SwiftLint' hinzu
  2. Fügen Sie dem Projekt eine neue "Skriptphase ausführen" hinzu.

    "${PODS_ROOT}/SwiftLint/swiftlint"
  3. SwiftLint .swiftlint.yml
  4. .swiftlint.yml , SwiftLint

Wenn das SwiftLint-Einbettungsprojekt bereits Code enthielt, müssen Sie geduldig sein und alle SwiftLint-Empfehlungen systematisch korrigieren. Er formt sie durch die üblichen Fehler- und Warnanzeigen mit umfassenden Tipps zu den Empfehlungen.



Außerdem wird in Klammern der Name der Regel angezeigt, die die Empfehlung initiiert hat (operator_usage_whitespace) .

In diesem Fall sind dies:

Operator-Verwendung Leerzeichen
Operatoren müssen von einem einzelnen Leerzeichen umgeben sein.

Richtiger Code:



Empfohlener Code:



Jede Regel hat eine Reihe von Attributen:

Kennung : operator_usage_whitespace
Standardmäßig aktiviert : deaktiviert
Unterstützt durch Autokorrektur :ja
Typ : style
Analyzer-Regel : Nein
Mindestversion des Swift-Compilers : 3.0.0
Standardkonfiguration : Warnung

Beachten Sie die „Mindestversion des Swift-Compilers“ - korrelieren Sie die Verwendung von Regeln mit diesem Attribut und den Einstellungen Ihres Projekts.

Das Attribut "Standardkonfiguration" zeigt, wie Regeln mit diesem Attribut wahrgenommen werden: entweder eine reguläre Warnung oder ein Kompilierungsfehler, z. B. eine Force Cast- Regel (Standardkonfiguration: Fehler).

Alle Regeln finden Sie in einer sehr praktischen und illustrierten Dokumentation.

Im Folgenden werde ich die Regeln vorstellen, die wir in unserem Team ausgewählt haben. Sie können sie als Beispiel verwenden, um Ihr Projekt zu erstellen.

Wir haben alle Regeln in funktionale und stilistische unterteilt - ja, ja, ja und ein Leerzeichen in jeder geschweiften Klammer, und die Schließparameter sollten in derselben Zeile wie die öffnende Klammer stehen und ... :). Ich male die Regeln nicht, Sie können leicht Informationen über sie über den obigen Link finden.

Funktionale :

- private_outlet
- force_unwrapping
- force_cast
- force_try
- strong_iboutlet
- private_action
- block_based_kvo
- contains_over_first_not_nil
- discarded_notification_center_observer
- discouraged_direct_init
- discouraged_object_literal
- discouraged_optional_boolean
- discouraged_optional_collection
- duplicate_imports
- dynamic_inline
- empty_count
- empty_parameters
- empty_parentheses_with_trailing_closure
- EMPTY_STRING
- explicit_enum_raw_value
- function_default_parameter_at_end
- generic_type_name
- identical_operands
- implicit_getter
- is_disjoint
- notification_center_detachment
- nsobject_prefer_isequal
- redundant_set_access_control
- unused_capture_list

Der Stil von :

- unneeded_parentheses_in_closure_argument
- let_var_whitespace
- yoda_condition
- Kolon
- Komma
- closure_parameter_position
- closure_spacing
- collection_alignment
- leading_whitespace
- mark
- opening_brace
- operator_usage_whitespace
- operator_whitespace
- protocol_property_accessors_order
- return_arrow_whitespace
- switch_case_alignment
- statement_position
- trailing_comma
- trailing_newline
- unneeded_break_in_switch
- custom_rules
- closure_end_indentation
- file_name_no_space
- unowned_variable_capture
- no_space_in_method_call
- contains_over_filter_count
- contains_over_filter_is_empty
- contains_over_range_nil_comparison
- duplicate_enum_cases
- empty_collection_literal

auch ein Ziel des SwiftLint wir , indem die entsprechenden Einstellungen in der Konfigurationsdatei .swiftlint.yml nur den Katalog mit unserer Code - Basis gewählt:

enthalten:

- <code Basisverzeichnis>

Wir haben die Regel für die Unzulässigkeit erstellt Druckfunktionen. Drucken ist eine ziemlich schwierige Operation. Über die Konfigurationsdatei .swiftlint.yml:

custom_rules:
  disable_print:
    included: ".*\\.swift"
    name: "print usage"
    regex: "((\\bprint)|(Swift\\.print))\\s*\\("
    message: "Prefer os_log over print"
    severity: error

Diese Regel veranlasste uns, unsere Protokollierungsfunktion (mit einer Protokollierungsstufe) zu schreiben. Diese Protokollierung wird von Entwicklern zum schnellen Debuggen verwendet. Beispielsweise werden Protokolle mit Parametern, Anforderungs- / Antworttext für die Analyse von Fehlern und für die Entwicklung benötigt. Für Release die Protokollstufe in unserer .none-Version. Der Rest der Verwendung der Druckfunktion führt zu einem Erstellungsfehler für das Projekt.

func logApp(level: Constants.LogLevel, items: Any...) {
    if Constants.logLevel == .none {
        return
    }
    
    if level.rawValue <= Constants.logLevel.rawValue {
        // swiftlint:disable disable_print
        if let strings = items as? [String] {
            for string in strings {
                print(string)
            }
        } else {
            print(items)
        }
        // swiftlunt:enable disable_print
    }

Um die Druckfunktion zu verwenden, mussten wir den Aufruf in unserer Protokollierungsfunktion mit SwiftLint schließen, um unsere eigenen Regeln für den mit einer speziellen Anweisung gekennzeichneten Codeblock zu ignorieren.

// swiftlint:disable disable_print
// swiftlunt:enable disable_print

SwiftLint kann seine eigenen Regeln ignorieren:

// swiftlint:disable <rule1 [rule2 rule3…]>
<,   SwiftLint   rule1 [rule2 rule3…]>
// swiftlunt:enable <rule1 [rule2 rule3…]>

Oder

// swiftlint:disable all
<,   SwiftLint   >
// swiftlint:enable all

Nutzen Sie diese Gelegenheit und wissen Sie, dass dies notwendig ist!

Abschließend stelle ich fest : Durch die Verwendung von SwiftLint in unserem Team konnten die Kosten für die manuelle Codeüberprüfung um 20% gesenkt werden. Jetzt achten unsere Prüfer nicht mehr auf typische Fehler (Force Cast usw.) und den Codestil und können sich voll und ganz auf die Überprüfung des neuen Codes konzentrieren. Dies hat die Effizienz des gesamten Teams erheblich gesteigert (keine Notwendigkeit, solche Fehler zu beheben, dies sind qualifizierte Mitarbeiter, deren Zeit sehr wichtig ist).

Alle! Jetzt ist SwiftLint für immer bei dir :)

More articles:


All Articles