Kod Linting

Hari ini adalah hari yang hebat, kerana saya perlu berusaha untuk menyepadukan ESLint ke dalam pangkalan kod kami! Saya monyet kod yang kelakar. Saya menikmati amalan pengekodan yang baik seperti linting, dokumentasi pengguna/teknikal/produk, ujian, kebolehcapaian dan keselamatan. Ini adalah topik yang biasanya tidak diberi keutamaan berbanding penghantaran kod berfungsi, kerana kod boleh berfungsi tanpa sebarang perkara yang saya senaraikan sebagai minat pengaturcaraan saya. Tetapi jika semua amalan tersebut dilaksanakan, kod itu jarang akan pecah (atau rosak) dan lebih kod yang boleh dipercayai. Mengapa tidak mencipta "kod kerja yang boleh dipercayai" dari awal?

Kenapa saya suka Linting?

Linting akan membantu anda menangkap ralat biasa lebih awal. Peraturan linting boleh mengenal pasti amalan pengekodan yang lemah, jadi pembangun tidak memperkenalkannya ke dalam projek. Linting boleh mengenal pasti masa untuk menggunakan const dan bukannya let, atau pembolehubah bayang, contohnya.

Mencegah kod buruk dengan linting, berbaloi dengan banyak pecutan menyahpepijat kod buruk.

Cabaran Saya

Kami mempunyai pangkalan kod sedia ada yang mempunyai banyak pembangun yang menyumbang. Kod tersebut mempunyai lebih daripada 5K pelanggaran linting selepas saya memasang ESLint dan menjalankan laporan. Saya mencari peraturan linting terbaik untuk digunakan dengan NextJS, TypeScript, A11y dan JavaScript. Oleh kerana terdapat begitu banyak pelanggaran, saya memutuskan untuk memburu kesilapan secara progresif. ESLint mempunyai ciri pembetulan automatik tetapi jangan sekali-kali menjalankannya pada pangkalan kod sedia ada dan mengharapkan ia berfungsi. Tidak, tidak, tidak ada anak muda. Kita mesti berulang!

Saya menetapkan peraturan kritikal kepada ❌ "ralat" dan selebihnya kepada "amaran" atau "mati". Kemudian saya menjalankan semula laporan untuk mengenal pasti perkara yang perlu diperbaiki sebelum menggunakan kod kami semula. Selepas semua ralat diperbaiki secara manual dan kod boleh dibina, saya menjalankan ujian unit kami untuk memastikan kami masih ✅ melepasi segala-galanya. Linting yang baik tidak boleh melanggar kod. Paling baik linting bertujuan untuk menyokong pembangun. Membantu pembangun junior mempelajari cara menulis kod yang lebih baik, kerana mereka perlu melakukannya.

Selepas semua ralat saya telah dikenal pasti dan diperbaiki ATAU diabaikan, maka kami boleh menggunakan dan mengetahui bahawa kod kami adalah sebaik yang kami boleh dapatkan "hari ini". Memandangkan pangkalan kod telah dibetulkan, kami boleh menggunakan "pembetulan-auto-magic" pada masa hadapan dan berasa yakin ia mempunyai peluang 50/50 untuk membetulkan ralat linting.

Pembelajaran Saya

Nampaknya ESLint telah dewasa! Ia tidak lagi akan menyokong beberapa lagi peraturan pemformatan kod, yang harus dikekalkan oleh perpustakaan pemformatan kod dan bukan perpustakaan linting. ESLint telah menamatkan banyak ciri pada v9 dan mengalihkan kebanyakan, jika tidak semua, kepada Stylistic!

Saya menggunakan Prettier untuk pemformatan kod dan Typescript mempunyai sokongan bendera dalam Stylistic jadi saya kekal dengan ESLint v8.53.0 supaya saya dapat mengekalkan pemformatan kod unggul ESLint. Tetapi akhirnya saya perlu berpindah ke 9 jadi ini hanya "menendang tin ke jalan raya".

Selamat Pengekodan!

Atas ialah kandungan terperinci Kod Linting. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!