Aturan SwiftLint Kustom

Hai Habr! Nama saya Alex, Saya Pengembang iOS di FINCH. Segera Tahun Baru adalah waktu untuk mulai hidup secara berbeda, dan hal yang keren seperti SwiftLint akan membantu dalam hal ini. Dalam artikel ini saya akan memberi tahu Anda mengapa itu harus diterapkan di semua proyek, termasuk proyek warisan dan hewan peliharaan, dan juga menunjukkan cara mendapatkan hasil maksimal dari alat ini menggunakan garis biasa.

Saya tidak akan memberi tahu Anda apa itu SwiftLint dan bagaimana cara menginstalnya - jika Anda tidak terbiasa dengan alat ini, maka lebih baik membaca dokumentasi resmi .

Lebih baik langsung ke masalah umum yang muncul ketika bekerja dengan proyek besar - ketidakpatuhan dengan panduan gaya dengan kedok perbaikan terbaru atau hal-hal lain. Tetapi pada kenyataannya, bahkan jika Anda membaca panduan gaya dan bahkan dapat memanggil mereka dalam keadaan mabuk ekstrim, tidak ada yang menjamin bahwa kesalahan ketik dangkal tidak dapat terjadi, yang, meskipun tidak memerlukan kerusakan logika, tetapi yang jelas akan mempengaruhi kesenangan estetika.

Jadi, ingat:

1. SwiftLint memungkinkan Anda melakukan:

  • Satu gaya dengan panduan gaya

Sebenarnya semuanya.

Artikel itu bisa berakhir di sini, tetapi jika demikian, saya tidak akan mulai menulis artikel ini sama sekali. Menariknya, SwiftLint tidak mengizinkan Anda melakukan - tuliskan ... kode perbaikan terbaru.

2. SwiftLint memungkinkan Anda untuk mencegah:

  • Paksa membuka bungkus
  • Delegasi yang kuat
  • Kompleksitas Siklomatik
  • Sesuatu yang lain ...

Saya pikir senang selamat dari kesalahan seperti itu, bukan? Ini sangat baik untuk pengembang pemula, karena ia hanya belajar dan kadang-kadang tidak mencurigai kesalahan tersebut.

3. Swiftlint dapat diperluas sesuai dengan aturannya sendiri.

Saya akan mulai dengan menentukan final untuk kelas yang tidak akan menjadi induk bagi orang lain. Berkat final, kami menghemat waktu perakitan proyek. Inilah yang dikatakan dokumentasi Apple tentang kelas akhir:
Deklarasi dengan akses internal (default jika tidak ada yang dideklarasikan) hanya terlihat di dalam modul di mana mereka dideklarasikan. Karena Swift biasanya mengkompilasi file yang membentuk modul secara terpisah, kompiler tidak dapat memastikan apakah deklarasi internal ditimpa dalam file yang berbeda atau tidak. Namun, jika Optimalisasi Seluruh Modul diaktifkan, semua modul dikompilasi bersamaan pada saat yang sama. Hal ini memungkinkan kompiler untuk membuat kesimpulan tentang seluruh modul bersama-sama dan menyimpulkan final pada deklarasi dengan internal jika tidak ada override yang terlihat.

Kami akan mengatasi kekurangan perhatian tersebut dengan musim reguler yang sederhana. Selanjutnya, saya akan segera menulis untuk ruby ​​sehingga Anda dapat memasukkan kode langsung ke proyek Anda:

final_class: included: ".*.swift" name: "Final class requrement" regex: '^class' message: "All classes must be final or nonfinal" saverity: error 

Contoh kecil dan cukup sederhana. Saya tidak akan menulis sesuatu yang serupa untuk setiap aturan, tetapi kode sumbernya ada di akhir artikel.

 class SomeClass { } //  internal class SomeClass { } //  /* @non-final */ class SomeClass { } //   

Poin selanjutnya diperlukan init. Kami di perusahaan tidak menggunakan storyboard, sehingga menetapkan penginisialisasi fatal di setiap kelas UIView tidak sepenuhnya normal. Untuk kasus ini, kami memiliki NLView kami sendiri (NL - NibLess) - kelas di mana init yang diperlukan diimplementasikan hanya sekali. Pengembang baru dalam proyek ini mungkin tidak mengetahui hal ini, tetapi manfaat SwiftLint selalu dimarahi alih-alih petunjuk yang bertanggung jawab. Atau dengan itu.

 required_init: regex: 'required init\?\(coder: NSCoder\)' message: "Use NL class instead" 

Jika Anda masih menggunakan storyboard, Anda dapat menggunakan aturan berikut untuk mengetahui bahwa semua storyboard Anda bersifat pribadi:

 open_iboutlets: included: ".*.swift" name: "IBOutlet opening" regex: '@IBOutlet ?(weak){0,1} var' message: "IBOutlet should be private" severity: error 

 open_ibaction: included: ".*.swift" name: "IBAction opening" regex: '@IBAction func' message: "IBAction should be private" severity: error 

Sering kali Yayasan digunakan di tempat yang sama sekali tidak perlu. Karena itu, lebih baik menyorotnya setiap kali agar tidak lupa:

  foundation_using: included: ".*.swift" regex: 'import Foundation' message: "Do you really need for Foundation ???" 

Saya harap semua orang tahu bahwa cetak adalah operasi yang agak sulit, yang dapat sangat merusak kinerja aplikasi (terutama dalam loop). Satu-satunya vonis - cetakan tidak boleh sama sekali.

 print_using: regex: 'print' message: "Print decrease performance of the app" severity: error 

Juga, Anda tidak boleh membuat protokol kelas saja, karena ada kemungkinan sintaks seperti itu akan segera menjadi usang dan ini tidak direkomendasikan oleh pengembang Swift .

 class_protocol: regex: ': class' message: "Use Anyobject instead" 

Di bawah ini adalah aturan untuk proyek yang menggunakan R.swift.

 image_name_initialization: included: ".*.swift" name: "Image initialization without R.swift" regex: 'UIImage\(named:[^)]+\)' message: "Use R.image.name() or typealias of this instead" severity: error 

Ini hanya sebagian kecil dari apa yang bisa saya pikirkan, tetapi ada lebih sedikit contoh di Internet. Anda dapat melihat seluruh "koleksi" saya di github .

Terima kasih atas perhatian anda Jika Anda juga menggunakan SwiftLint dengan aturan khusus, maka beri tahu kami tentang hal itu - saya akan dengan senang hati mendiskusikan kemungkinan kasus.

Source: https://habr.com/ru/post/id481666/


All Articles