Pylint dari dalam ke luar. Bagaimana dia melakukannya?

Berbagai pembantu dalam menulis kode keren hanya mengelilingi kita, linter, typekchera, utilitas untuk menemukan kerentanan, semua bersama kita. Kami sudah terbiasa dan menggunakannya tanpa masuk ke detail seperti "kotak hitam". Misalnya, beberapa orang memahami prinsip-prinsip Pylint, salah satu alat yang sangat diperlukan untuk mengoptimalkan dan meningkatkan kode Python.

Tapi Maxim Mazaev tahu betapa pentingnya memahami alat-alatnya, dan dia memberi tahu kami di Moscow Python Conf ++ . Dengan menggunakan contoh nyata, ia menunjukkan bagaimana pengetahuan tentang perangkat internal Pylint dan plug-in-nya membantu mengurangi waktu peninjauan kode, meningkatkan kualitas kode, dan umumnya meningkatkan efisiensi pengembangan. Di bawah ini adalah instruksi dekripsi.

Mengapa kita membutuhkan Pylint?

Jika Anda sudah menggunakannya, pertanyaan mungkin timbul: "Mengapa tahu apa yang ada di dalam Pylint, bagaimana pengetahuan ini bisa membantu?"

Biasanya, pengembang menulis kode, meluncurkan linter, menerima pesan tentang apa yang harus ditingkatkan, bagaimana membuat kode lebih indah, dan membuat perubahan yang diajukan. Sekarang kode lebih mudah dibaca dan tidak malu untuk menunjukkan kepada rekan kerja.

Untuk waktu yang lama, mereka bekerja dengan cara yang persis sama dengan Pylint di Cyan Institute, dengan tambahan kecil: mereka mengubah konfigurasi, menghapus aturan yang tidak perlu, dan meningkatkan panjang string maksimum.

Tetapi pada suatu saat mereka mengalami masalah, di mana saya harus menggali jauh ke dalam Pylint dan mencari tahu cara kerjanya. Apa masalah ini dan bagaimana mengatasinya, baca terus.


Tentang pembicara: Maxim Mazaev ( backslash ), 5 tahun dalam pengembangan, bekerja di CIAN. Sangat mempelajari pemrograman Python, asynchrony dan fungsional.

Tentang cyan

Sebagian besar percaya bahwa CIAN adalah agen real estat dengan agen penjual dan sangat terkejut ketika mereka mengetahui bahwa alih-alih agen penjual kami memiliki programmer.

Kami adalah perusahaan teknis di mana tidak ada agen penjual, tetapi ada banyak programmer.

• 1 juta pengguna unik per hari.
• Papan buletin terbesar untuk penjualan dan penyewaan real estat di Moskow dan St. Petersburg. Pada 2018, mereka memasuki tingkat federal dan bekerja di seluruh Rusia.
• Hampir 100 orang di tim pengembangan, 30 di antaranya menulis kode Python setiap hari.

Setiap hari, ratusan dan ribuan baris kode baru mulai diproduksi. Persyaratan untuk kode ini cukup sederhana:

• Kode kualitas yang layak.
• Homogenitas gaya. Semua pengembang harus menulis kira-kira kode yang sama, tanpa "vinaigrette" di repositori.

Untuk mencapai ini, tentu saja, Anda memerlukan peninjauan kode.

Ulasan kode

Ulasan kode dalam CIAN berlangsung dalam dua tahap:

1. Tahap pertama adalah otomatis . Robot Jenkins menjalankan tes, menjalankan Pylint, dan memeriksa konsistensi API antara layanan microser, karena kami menggunakan layanan microser. Jika pada tahap ini tes gagal atau linter menunjukkan sesuatu yang aneh, maka ini adalah kesempatan untuk menolak permintaan tarikan dan mengirim kode untuk revisi.
   
2. Jika tahap pertama berhasil, maka yang kedua datang - persetujuan dari dua pengembang . Mereka dapat mengevaluasi seberapa baik kode dalam hal logika bisnis, menyetujui permintaan tarik atau mengembalikan kode untuk revisi.
   

Masalah tinjauan kode

Permintaan tarik mungkin tidak lulus ulasan kode karena:

• kesalahan dalam logika bisnis saat pengembang memecahkan masalah secara tidak efektif atau salah;
• masalah gaya kode.

Apa yang bisa menjadi masalah gaya jika linter memeriksa kode?

Setiap orang yang menulis dengan Python tahu bahwa ada panduan untuk menulis kode PEP-8 . Seperti standar apa pun, PEP-8 cukup umum dan bagi kami, sebagai pengembang, ini tidak cukup. Saya ingin menentukan standar di beberapa tempat, dan memperluas di tempat lain.

Oleh karena itu, kami membuat pengaturan internal tentang bagaimana kode seharusnya terlihat dan berfungsi, dan menyebutnya "Tolak Proposal Cian" .



“Decline Cian Proposals” - seperangkat aturan, sekarang ada sekitar 15. Masing-masing aturan ini adalah dasar untuk permintaan penarikan ditolak dan dikirim untuk direvisi.

Apa yang menghalangi tinjauan kode produktif?

Ada satu masalah dengan aturan internal kita - si lemah tidak tahu tentang mereka, dan akan aneh jika dia tahu - itu adalah internal.

Pengembang yang melakukan tugas harus selalu mengingat dan mengingat aturan. Jika dia lupa salah satu aturan, maka dalam proses peninjauan kode, pengulas akan menunjukkan masalahnya, tugasnya akan direvisi dan waktu rilis tugas akan bertambah. Setelah selesai dan koreksi kesalahan, penguji perlu mengingat apa yang ada di tugas, untuk mengganti konteks.

Ini menciptakan masalah bagi pengembang dan pengulas. Akibatnya, kecepatan tinjauan kode berkurang secara kritis. Alih-alih menganalisis logika kode, para penguji mulai menganalisis gaya visual, yaitu, mereka melakukan pekerjaan linter: mereka memindai baris kode demi baris dan mencari inkonsistensi dalam lekukan dalam format impor.

Kami ingin menyingkirkan masalah ini.

Tapi jangan tulis kami daftar Anda?

Tampaknya masalah akan diselesaikan oleh alat yang akan tahu tentang semua perjanjian internal dan akan dapat memeriksa kode untuk implementasinya. Jadi kita membutuhkan linter kita sendiri?

Tidak juga. Idenya bodoh, karena kita sudah menggunakan Pylint. Ini adalah linter nyaman, disukai oleh pengembang dan dibangun ke dalam semua proses: ini berjalan di Jenkins, menghasilkan laporan indah yang benar-benar puas dan datang dalam bentuk komentar dalam permintaan tarik. Semuanya baik-baik saja, linter kedua tidak diperlukan .

Jadi bagaimana mengatasi masalah jika kita tidak ingin menulis linter kita sendiri?

Tulis Plugin Pylint

Anda dapat menulis plugin untuk Pylint, mereka disebut checker. Di bawah setiap aturan internal, Anda dapat menulis pemeriksa Anda sendiri, yang akan memeriksanya.

Perhatikan dua contoh biji seperti itu.

Contoh No. 1

Pada titik tertentu, ternyata kode tersebut berisi banyak komentar dari bentuk "TODO" - berjanji untuk melakukan refactor, menghapus kode yang tidak perlu atau menulis ulang dengan indah, tetapi tidak sekarang, tetapi nanti. Ada masalah dengan komentar seperti itu - mereka sama sekali tidak mengharuskan Anda untuk apa pun.

Masalah

Pengembang menulis janji, menghembuskan napas dan pergi dengan tenang untuk melakukan tugas selanjutnya.


Singkatnya:

• komentar dengan janji menggantung selama bertahun-tahun dan tidak diikuti;
• kode dikotori;
• hutang teknis telah menumpuk selama bertahun-tahun.

Misalnya, pengembang 3 tahun lalu berjanji untuk menghapus sesuatu setelah rilis berhasil, tetapi apakah rilis itu terjadi dalam 3 tahun? Mungkin ya. Haruskah saya menghapus kode dalam hal ini? Ini adalah pertanyaan besar, tetapi kemungkinan besar tidak.

Solusi: tulis checker Anda untuk Pylint

Anda tidak bisa melarang pengembang untuk menulis komentar seperti itu, tetapi Anda bisa membuatnya bekerja ekstra: buat tugas di pelacak untuk menyelesaikan janji. Maka kita pasti tidak akan melupakannya.

Kami perlu menemukan semua komentar dari formulir TODO dan memastikan bahwa masing-masing dari mereka memiliki tautan ke tugas di Jira. Ayo kita tulis.

Apa itu pemeriksa dalam hal Pylint? Ini adalah kelas yang mewarisi dari kelas dasar pemeriksa dan mengimplementasikan antarmuka tertentu.

class TodoIssueChecker(BaseChecker): _ _implements_ _ = IRawChecker 

Dalam kasus kami, ini adalah IRawChecker - pemeriksa "mentah".

Pemeriksa mentah beralih pada baris file dan dapat melakukan tindakan tertentu pada sebuah baris. Dalam kasus kami, pada setiap baris, pemeriksa akan mencari sesuatu yang mirip dengan komentar dan tautan ke tugas.

Untuk pemeriksa, Anda perlu menentukan daftar pesan yang akan dikeluarkannya:

 msgs = { '9999': ('  TODO    ', issue-code-in-todo', ' ')} 

Pesannya memiliki:

• deskripsinya pendek dan panjang;
• kode checker dan nama mnemonic pendek yang menentukan jenis pesan apa itu.

Kode pesan memiliki bentuk "C1234", di mana:

• Huruf pertama jelas terstandarisasi untuk berbagai jenis pesan: [C] pencegahan; [W] mulai ; [E] yog; [F] atal; [R] efactoring. Berkat surat itu, laporan segera menunjukkan apa yang terjadi: pengingat perjanjian atau masalah fatal yang perlu segera diatasi.
• 4 angka acak unik untuk Pylint.

Kode diperlukan untuk menonaktifkan pemeriksaan jika menjadi tidak perlu. Anda dapat menulis Pylint: disable dan kode alfanumerik pendek atau nama mnemonik:

 # Pylint: disable=C9999 # Pylint: disable=issue-code-in-todo 

Para penulis Pylint merekomendasikan untuk meninggalkan kode alfanumerik dan menggunakan mnemonik, itu lebih visual.

Langkah selanjutnya adalah mendefinisikan metode yang disebut process_module .



Nama itu sangat penting. Metode ini harus dipanggil seperti itu, karena Pylint kemudian akan memanggilnya.

Parameter simpul diteruskan ke modul. Dalam hal ini, tidak masalah apa itu atau tipe apa itu, penting untuk diingat bahwa node memiliki metode stream yang mengembalikan file baris demi baris.

Anda dapat melihat file dan untuk setiap baris memeriksa komentar dan tautan ke tugas. Jika ada komentar, tetapi tidak ada tautan, maka berikan peringatan berupa 'issue-code-in-todo' dengan kode checker dan nomor baris. Algoritma ini cukup sederhana.

Daftarkan checker sehingga Pylint mengetahuinya. Ini dilakukan oleh fungsi register :

 def register(linter: Pylinter) -> None: linter. register_checker ( TodoIssueChecker(linter) ) 

• Contoh Pylint masuk ke fungsi.
• Itu memanggil metode register_checker.
• Kami melewati pemeriksa ke metode.

Poin penting: modul checker harus dalam PYTHONPATH sehingga Pylint dapat mengimpornya nanti.

Pemeriksa terdaftar diperiksa oleh file uji dengan komentar tanpa tautan ke tugas.

 $ cat work. # T0D0:   , -! $ pylint work. --load-plugins todo_checker … 

Untuk pengujian, jalankan Pylint, berikan modul ke modul tersebut, gunakan parameter load-plugins untuk melewati pemeriksa, dan di dalam linter, jalankan dua fase.

Fase 1. Inisialisasi Plugin

• Semua modul dengan plugin diimpor. Pylint memiliki checker internal dan eksternal. Mereka semua datang bersama dan diimpor.
• Kami mendaftar - module.register (mandiri) . Untuk setiap pemeriksa, fungsi register dipanggil, tempat instance Pylint dilewatkan.
• Pemeriksaan dilakukan: untuk validitas parameter, untuk keberadaan pesan, opsi, dan laporan dalam format yang benar.

Fase 2. Mengurai kumpulan biji

Setelah fase 1, seluruh daftar berbagai jenis biji tetap:

• Pemeriksa AST;
• Pemeriksa mentah;
• Pemeriksa token.

Dari daftar kami memilih yang berhubungan dengan antarmuka pemeriksa mentah: kami melihat di mana checker mengimplementasikan antarmuka IRawChecker dan membawanya sendiri.

Untuk setiap pemeriksa terpilih, panggil metode checker.process_module (modul) , dan jalankan pemeriksaan.

Hasil

Jalankan pemeriksa pada file tes lagi:

 $ cat work. # T0D0:   , -! $ pylint work,  --load-plugins todo_checker : 0,0:   T0D0     (issue-code-in-todo) 

Sebuah pesan akan muncul yang menyatakan bahwa ada komentar dengan TODO dan tidak ada tautan ke tugas tersebut.

Masalahnya terpecahkan dan sekarang dalam proses peninjauan kode, pengembang tidak perlu memindai kode dengan mata mereka, menemukan komentar, menulis pengingat kepada pembuat kode bahwa ada perjanjian dan disarankan untuk meninggalkan tautan. Semuanya terjadi secara otomatis dan tinjauan kode sedikit lebih cepat.

Contoh No. 2. argumen-kata kunci

Ada fungsi yang mengambil argumen posisi. Jika ada banyak argumen, maka ketika mereka memanggil fungsi, tidak begitu jelas di mana argumen itu dan mengapa itu diperlukan.

Masalah

Misalnya, kami memiliki fungsi:

 get_offer_by_cian_id( "sale", rue, 859483, ) 

Kode telah dijual dan Benar, dan tidak jelas apa artinya. Ini jauh lebih nyaman ketika fungsi di mana ada banyak argumen akan dipanggil hanya dengan argumen bernama:

 get_offer_by_cian_id( deal_type="sale", truncate=True, cian_id=859483, ) 

Ini adalah kode yang baik, di mana langsung jelas di mana parameternya dan kami tidak akan mengacaukan urutannya. Mari kita coba menulis pemeriksa yang memeriksa kasus-kasus seperti itu.

Pemeriksa "mentah" yang digunakan dalam contoh sebelumnya sangat sulit untuk ditulis untuk kasus seperti itu. Anda dapat menambahkan ekspresi reguler super-kompleks, tetapi kode seperti itu sulit dibaca. Adalah baik bahwa Pylint memungkinkan untuk menulis jenis pemeriksa lain berdasarkan pohon sintaksis AST abstrak, dan kita akan menggunakannya.

Lirik tentang AST

AST atau pohon sintaksis abstrak adalah representasi pohon dari kode, di mana verteks adalah operan dan daun adalah operator.

Misalnya, panggilan fungsi, di mana ada satu argumen posisi dan dua argumen bernama, diubah menjadi pohon abstrak:


Ada simpul dengan tipe Panggilan dan memiliki:

• atribut fungsi yang disebut func;
• daftar argumen posisi, di mana ada simpul dengan tipe Const dan nilai 112;
• daftar argumen bernama Kata kunci.

Tugas dalam hal ini:

• Temukan di modul semua node dengan tipe Call (panggilan fungsi).
• Hitung jumlah total argumen yang digunakan fungsi.
• Jika ada lebih dari 2 argumen, maka pastikan tidak ada argumen posisional dalam simpul tersebut.
• Jika ada argumen posisi, maka perlihatkan peringatan.

 ll( func=Name(name='get_offer'), args=[Const(value=1298880)], keywords=[ … ]))] 

Dari sudut pandang Pylint, pemeriksa berbasis AST adalah kelas yang mewarisi dari kelas pemeriksa basis dan mengimplementasikan antarmuka IAstroidChecker :

 class NonKeywordArgsChecker(BaseChecker): -_ _implements_ _ = IAstroidChecker 

Seperti pada contoh pertama, deskripsi checker, kode pesan, nama mnemonik pendek ditunjukkan dalam daftar pesan:

 msgs = { '9191': (' ', keyword-only-args', ' ')} 

Langkah selanjutnya adalah menentukan metode kunjungan_panggilan:

 def visit_call(self, node: Call) … 

Metodenya tidak harus disebut itu. Yang paling penting di dalamnya adalah awalan visit_, dan kemudian muncul nama titik yang menarik bagi kita, dengan huruf kecil.

• Parser AST berjalan melalui pohon dan untuk setiap vertex terlihat untuk melihat apakah kunjungan checkr antarmuka_ <Nama> didefinisikan.
• Jika demikian, sebut saja.
• Secara rekursif melewati semua anak-anaknya.
• Saat meninggalkan simpul, ia memanggil metode leave_ <Name>.

Dalam contoh ini, metode visit_call akan menerima node tipe-panggilan sebagai input dan melihat apakah ada lebih dari dua argumen dan apakah ada argumen posisi untuk melemparkan peringatan dan meneruskan kode ke node itu sendiri.

 def visit_call(self, n): if node.args and len(node.args + node.keywords) > 2: self.add_message( 'keyword-only-args', node=node ) 

Kami mendaftarkan pemeriksa, seperti pada contoh sebelumnya: kami mentransfer instance Pylint, memanggil register_checker, melewati pemeriksa itu sendiri dan memulainya.

 def register(linter: Pylinter) -> None: linter.register_checker( TodoIssueChecker(linter) ) 

Ini adalah contoh panggilan fungsi tes di mana ada 3 argumen dan hanya satu yang bernama:

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker … 

Ini adalah fungsi yang berpotensi disebut salah dari sudut pandang kami. Luncurkan Pylint.

Inisialisasi plugin tahap 1 benar-benar diulang, seperti pada contoh sebelumnya.

Fase 2. Modul parsing di AST

Kode diuraikan menjadi pohon AST. Analisis dilakukan oleh perpustakaan Astroid .

Mengapa Astroid, bukan AST (stdlib)

Astroid secara internal tidak menggunakan modul AST Python standar, tetapi parser AST yang diketik typed_ast , dicirikan dengan mendukung petunjuk jenis PEP 484. Typed_ast adalah cabang AST, garpu yang berkembang secara paralel. Menariknya, ada bug yang sama yang ada di AST, dan diperbaiki secara paralel.

 from module import Entity def foo(bar): # type: (Entity) -> None return 

Sebelumnya, Astroid menggunakan modul AST standar, di mana orang bisa menghadapi masalah menggunakan taiphints yang didefinisikan dalam komentar yang digunakan dalam Python kedua. Jika Anda memeriksa kode ini melalui Pylint, maka pada titik tertentu kode ini akan bersumpah pada impor yang tidak digunakan, karena kelas Entitas yang diimpor hanya ada di komentar.

Pada suatu titik, Guido Van Rossum datang ke Astroid di GitHub dan berkata: "Guys, Anda punya Pylint, yang bersumpah pada kasus-kasus seperti itu, dan kami memiliki pengurai AST yang diketik yang mendukung semua ini. Mari berteman! "

Pekerjaan sudah mulai mendidih! 2 tahun berlalu, Pylint musim semi ini beralih ke pengurai AST yang diketik dan berhenti bersumpah pada hal-hal seperti itu. Impor untuk taiphint tidak lagi ditandai sebagai tidak digunakan.

Astroid menggunakan parser AST untuk mengurai kode menjadi pohon, dan kemudian melakukan beberapa hal menarik ketika membangunnya. Misalnya, jika Anda menggunakan impor * , maka impor semuanya dengan tanda bintang dan tambahkan ke penduduk lokal untuk mencegah kesalahan dengan impor yang tidak digunakan.

Plugin transformasi digunakan dalam kasus di mana ada beberapa model kompleks berdasarkan kelas meta, ketika semua atribut dihasilkan secara dinamis. Dalam hal ini, Astroid sangat sulit untuk memahami apa yang dimaksud. Saat memeriksa, Pylint akan bersumpah bahwa model tidak memiliki atribut seperti itu ketika diakses, dan menggunakan plugin Transform Anda dapat menyelesaikan masalah:

• Bantu Astroid memodifikasi pohon abstrak dan memahami sifat dinamis Python.
• Tambahan AST dengan informasi yang berguna.

Contoh tipikal adalah pylint-django . Ketika bekerja dengan model Django kompleks, linter sering bersumpah pada atribut yang tidak diketahui. Pylint-Django baru saja menyelesaikan masalah ini.

Fase 3. Mengurai kumpulan biji

Kami kembali ke pemeriksa. Kami lagi memiliki daftar checker, dari mana kami menemukan orang-orang yang mengimplementasikan antarmuka AST checker.

Fase 4. Parse checker berdasarkan jenis node

Selanjutnya, kami menemukan metode untuk setiap pemeriksa, mereka bisa dari dua jenis:

• visit_ <Nama Node>
• lev_ <Node name>.

Akan menyenangkan untuk mengetahui node apa yang perlu Anda panggil untuk node saat berjalan di pohon. Oleh karena itu, mereka memahami kamus, di mana kuncinya adalah nama node, nilainya adalah daftar checker yang tertarik pada fakta akses ke node ini.

 _visit_methods = dict( < > : [checker1, checker2 ... checkerN] ) 

Sama dengan metode meninggalkan: kunci dalam bentuk nama node, daftar checker yang tertarik pada fakta keluar dari node ini.

 _leave_methods = dict( < >: [checker1, checker2 ... checkerN] ) 

Luncurkan Pylint. Itu menunjukkan peringatan bahwa kita memiliki fungsi di mana ada lebih dari dua argumen dan ada argumen posisional di dalamnya:

 $ cat work. get_offers(1, True, deal_type="sale") $ Pylint work.py --load-plugins non_kwargs_checker C: 0, 0:  c >2      (keyword-only-args) 

Masalahnya teratasi. Sekarang, programmer pengkaji kode tidak perlu membaca argumen dari fungsi, linter akan melakukannya untuk mereka. Kami menghemat waktu , waktu untuk meninjau kode, dan tugas kami berjalan lebih cepat dalam produksi.

Dan untuk menulis tes?

Pylint memungkinkan Anda untuk melakukan pengujian unit catur dan sangat sederhana. Dari sudut pandang linter, pemeriksa tes terlihat seperti kelas yang mewarisi dari CheckerTestCase abstrak. Diperlukan untuk menunjukkan pemeriksa yang sedang diperiksa di dalamnya.

 class TestNonKwArgsChecker(CheckerTestCase): CHECKER_CLASS = NonKeywordArgsChecker 

Langkah 1. Kami membuat tes AST-node dari bagian kode yang kami periksa.

 node = astroid.extract_node( "get_offers(3, 'magic', 'args')" ) 

Langkah 2. Verifikasi bahwa pemeriksa, memasuki simpul, apakah melempar atau tidak melempar pesan yang sesuai:

 with self.assertAddsMessages(message): self.checker.visit_call(node) 

Tokenchecker

Ada jenis pemeriksa lain yang disebut TokenChecker . Ia bekerja berdasarkan prinsip penganalisa leksikal. Python memiliki modul tokenize yang berfungsi sebagai pemindai leksikal dan memecah kode menjadi daftar token. Mungkin terlihat seperti ini:


Nama variabel, nama fungsi, dan kata kunci menjadi token bertipe NAME, dan pembatas, tanda kurung, titik dua menjadi token bertipe OP. Selain itu, ada token terpisah untuk lekukan, umpan baris, dan terjemahan terbalik.

Bagaimana Pylint bekerja dengan TokenChecker:

• Modul yang sedang diuji tokenized.
• Daftar besar token diteruskan ke semua checker yang mengimplementasikan ITokenChecker dan metode process_tokens (token) dipanggil .

Kami belum menemukan penggunaan TokenChecker, tetapi ada beberapa contoh yang digunakan Pylint:

• Periksa ejaan . Misalnya, Anda dapat mengambil semua token dengan jenis teks dan melihat literasi leksikal, memeriksa kata-kata dari daftar stop-word, dll.
• Periksa indentasi , spasi.
• Bekerja dengan string . Misalnya, Anda dapat memverifikasi bahwa Python 3 tidak menggunakan literal Unicode, atau memverifikasi bahwa hanya karakter ASCI yang ada dalam string byte.

Kesimpulan

Kami punya masalah dengan ulasan kode. Para pengembang melakukan pekerjaan linter, menghabiskan waktu mereka pada pemindaian kode tanpa tujuan dan memberi tahu penulis tentang kesalahan. Dengan Pylint kami:

• Ditransfer cek rutin ke linter, mengimplementasikan perjanjian internal di dalamnya.
• Peningkatan tinjauan kecepatan dan kualitas kode.
• Mengurangi jumlah permintaan tarik yang ditolak, dan waktu untuk melewati tugas dalam produksi menjadi lebih sedikit.

Pemeriksa sederhana ditulis dalam setengah jam, dan pemeriksa rumit dalam beberapa jam. Pemeriksa menghemat lebih banyak waktu daripada yang diperlukan untuk menulis dan berjuang untuk beberapa permintaan tarik yang tidak ditolak.

Anda dapat mempelajari lebih lanjut tentang Pylint dan cara menulis biji catur di dokumentasi resmi , tetapi dalam hal menulis biji catur agak buruk. Sebagai contoh, tentang TokenChecker hanya ada menyebutkan bahwa itu ada, tetapi bukan tentang bagaimana menulis checker itu sendiri. Informasi lebih lanjut tersedia di sumber Pylint di GitHub . Anda dapat melihat catur apa yang ada dalam paket standar dan mendapatkan inspirasi untuk menulis sendiri.

Pengetahuan tentang desain internal Pylint menghemat waktu, disederhanakan
kinerja dan meningkatkan kode. Hemat waktu Anda, tulis kode yang baik dan
gunakan linter.

Konferensi Moscow Python Conf ++ berikutnya akan diadakan pada tanggal 5 April 2019 dan Anda sudah dapat memesan tiket birf awal sekarang. Bahkan lebih baik untuk mengumpulkan pikiran Anda dan melamar laporan, maka kunjungan akan gratis, dan roti manis akan menjadi bonus, termasuk pelatihan tentang persiapan laporan.

Konferensi kami adalah platform untuk bertemu dengan orang-orang yang berpikiran sama, mesin industri, untuk berkomunikasi dan mendiskusikan hal-hal yang disukai pengembang Python: backend dan web, pengumpulan dan pemrosesan data, AI / ML, pengujian, IoT. Bagaimana kelanjutannya di musim gugur, lihat laporan video di Saluran Python kami dan berlangganan saluran - segera kami akan memposting laporan terbaik dari konferensi untuk akses gratis.