Get best of the week

Menggunakan SwiftLint Static Code Analyzer di Aplikasi iOS Mobile Banking

Oleg Ivanov, Kepala Pusat Kompetensi untuk Saluran Layanan Jarak Jauh



Halo semuanya! Seperti yang dijanjikan dalam artikel "Bank Mobile ICD: Sejarah Pengembangan" , hari ini saya ingin berbicara tentang penganalisa kode statis dan pengalaman aplikasi mereka dalam aplikasi mobile iOS bank.

Mari kita tetapkan tujuan yang ingin kita capai menggunakan toolkit ini:

  • deteksi dini kesalahan dan kekurangan;
  • Code Style ( — , ).

Cara umum untuk mencapai tujuan kami adalah dengan memeriksa kode secara manual - Tinjauan kode .

Penguji atau sekelompok penguji memeriksa kode dengan hati-hati, kemudian mereka mengidentifikasi kesalahan atau bagian dari kode yang mungkin keliru di masa depan, dan memberikan rekomendasi untuk memperbaikinya melalui komentar pada kode, yang setelah beberapa saat (!) Akan dianalisis dan diperbaiki oleh pengembang. Seperti yang dapat kita lihat, proses verifikasi kode yang panjang dan mahal muncul. Plus, selalu ada faktor manusia - beberapa kesalahan dapat dengan mudah dilewati oleh pengulas.

Di sini, penganalisa kode statis datang membantu kami.

Analisis Kode Statis- memulai proses otomatis untuk mendeteksi kesalahan dan kekurangan dalam kode sumber program.

Analisis kode statis bukanlah obat mujarab atau pengganti untuk tinjauan Kode manual, tetapi mereka adalah alat yang sangat baik yang memungkinkan Anda untuk mengurangi waktu yang diperlukan untuk melakukan pemeriksaan dan dengan cepat menemukan kesalahan yang terpola. Relevansi menggunakan penganalisa statis hanya akan tumbuh seiring waktu.

Sebagai penganalisa kode statis dalam proyek iOS kami, kami menggunakan SwiftLint.

SwiftLint adalah utilitas pemeriksaan otomatis kode Swift yang berjalan selama fase pembangunan suatu proyek. Utilitas ini berisi seperangkat aturan dengan kemampuan untuk melengkapi set ini dengan aturan khusus Anda. Alat ini juga digunakan untuk mematuhi Gaya Kode.

Mengapa penting untuk mengikuti Gaya Kode dalam aplikasi?
Ketika Anda adalah salah satu pengembang dalam suatu proyek, semuanya sederhana: Anda menulis dengan gaya Anda sendiri dan Anda mampu membeli kode dengan cara ini:



Tetapi ketika Anda bekerja di tim pengembangan besar. faktor penting adalah kecepatan pemahaman dan menemukan tempat untuk memasukkan perbaikan ke dalam kode orang lain.
Dan di sini semua anggota tim harus menerima konvensi dan aturan untuk menulis kode. Tetapi bagaimana cara memeriksa kepatuhan mereka? Sekali lagi, penganalisa kode statis SwiftLint akan membantu kami. Dan kode kami akan terlihat menyenangkan sehingga setiap anggota tim akan mengerti:



Untuk berkenalan dengan alat ini, saya sarankan membaca dokumentasi resmi .

Menginstal SwiftLint sederhana:

  1. Tambahkan pod 'SwiftLint' ke podfile proyek
  2. Tambahkan "Run Script Phase" baru ke proyek.

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

Jika proyek penyematan SwiftLint sudah mengandung kode, Anda harus bersabar dan secara sistematis memperbaiki semua rekomendasi SwiftLint. Dia membentuk mereka melalui tampilan kesalahan dan peringatan yang biasa dengan tips komprehensif tentang rekomendasi.



Juga dalam tanda kurung, ini menampilkan nama aturan yang memulai rekomendasi (operator_usage_whitespace) .

Dalam hal ini, ini adalah:

Penggunaan Ruang
Operator Ruang Operator harus dikelilingi oleh satu ruang.

Kode yang benar: Kode yang



disarankan:



Setiap aturan memiliki seperangkat atribut:

Identifier : operator_usage_whitespace
Diaktifkan pada pengaturan standar : dinonaktifkan
Didukung oleh koreksi otomatis :ya
Tipe : style
Aturan analisis : Tidak
Versi minimum dari kompiler Swift : 3.0.0
Konfigurasi default : peringatan

Perhatikan “Versi minimum kompiler Swift” - menghubungkan penggunaan aturan dengan atribut ini dan dengan pengaturan proyek Anda.

Atribut “Konfigurasi default” menunjukkan bagaimana aturan dengan atribut ini akan dirasakan: baik peringatan reguler, atau kesalahan kompilasi, seperti aturan Force Cast (Konfigurasi default: kesalahan)

Semua aturan dapat ditemukan dalam dokumentasi yang sangat nyaman dan bergambar.

Di bawah ini saya akan menyajikan aturan yang telah kami pilih dalam tim kami, Anda dapat menggunakannya sebagai contoh untuk membuat proyek Anda.

Kami membagi semua aturan menjadi fungsional dan bergaya - ya, ya, ya, dan satu ruang di dalam masing-masing kurung kurawal, dan parameter penutup harus berada di baris yang sama dengan braket pembuka, dan ... :). Saya tidak melukis aturannya, Anda dapat dengan mudah menemukan informasi tentang mereka menggunakan tautan di atas.

Fungsional :

- private_outlet
- force_unwrapping
- force_cast
- force_try
- strong_iboutlet
- private_action
- block_based_kvo
- berisi_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

Gaya :

- unneeded_parentheses_in_closure_argument
- let_var_whitespace
- yoda_condition
- usus
- koma
- 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

juga tujuan dari SwiftLint kami memilih hanya katalog dengan basis kode kita dengan menambahkan pengaturan yang sesuai di .swiftlint.yml file konfigurasi:

termasuk:

- <direktori dasar code>

Kami telah membuat aturan untuk dapat diterimanya fungsi cetak. cetak adalah operasi yang cukup sulit. Melalui file konfigurasi .swiftlint.yml:

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

Aturan ini mendorong kami untuk menulis fungsi logging kami (dengan level logging). Pencatatan ini digunakan oleh pengembang untuk debugging cepat, misalnya, log dengan parameter, badan permintaan / respons diperlukan untuk setiap analisis kesalahan, untuk pengembangan. Untuk Rilis, tingkat log dalam versi .none kami. Sisa penggunaan fungsi cetak akan menghasilkan kesalahan build untuk proyek.

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
    }

Tetapi untuk menggunakan fungsi cetak, kami harus menutup panggilannya di fungsi logging kami menggunakan SwiftLint untuk mengabaikan aturan kami sendiri pada blok kode yang ditandai dengan instruksi khusus.

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

SwiftLint memiliki kemampuan untuk mengabaikan aturannya sendiri:

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

Atau

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

Gunakan kesempatan ini, sadari sepenuhnya bahwa itu perlu!

Sebagai kesimpulan, saya perhatikan : penggunaan SwiftLint di tim kami mengurangi biaya tinjauan Kode manual sebesar 20%. Sekarang pengulas kami tidak memperhatikan kesalahan umum (Force Cast, dll.), Gaya Kode dan dapat sepenuhnya berkonsentrasi pada memeriksa kode baru. Yang secara signifikan meningkatkan efisiensi tim secara keseluruhan (tidak perlu memperbaiki kesalahan pengecekan, ini adalah karyawan yang memenuhi syarat, yang waktunya sangat penting).

Semua! Sekarang SwiftLint selamanya bersama Anda :)

More articles:


All Articles