Kod buruk seperti najis, adakah anda menyukainya?

Terdapat projek di GitHub yang menerangkan sembilan belas prinsip utama untuk "kod sampah terbaik". Daripada penamaan berubah-ubah kepada penulisan ulasan. Garis panduan ini akan membimbing anda dalam menulis kod buruk terbaik yang anda boleh.

Untuk mengekalkan gaya yang sama seperti projek GitHub asal, tiada penukaran di bawah. Pembaca boleh memahami semua sudut pandangan dari perspektif yang bertentangan, yang merupakan cara terbaik untuk mengelak daripada menulis kod sampah.

Alamat projek:
https://github.com/trekhleb/state-of-the-art-shitcode

Sudah tentu, sembilan belas garis panduan menulis kod sampah berikut tidak lengkap jika pembaca mendapatinya Adakah Anda juga boleh menyatakan pendapat anda tentang beberapa tabiat pengekodan buruk yang tidak tertanggung.

? Artikel 1: Semakin kurang menaip, semakin baik

Jika kita kurang menaip, kita mempunyai lebih banyak masa untuk memikirkan logik kod dan isu-isu lain. Seperti yang ditunjukkan di bawah, "Baik" menunjukkan contoh yang mengikut peraturan dan "Buruk" menunjukkan contoh yang tidak mengikut peraturan.

? Perkara 2: Gaya penamaan campuran pembolehubah/fungsi

Kita perlu mencampurkan kaedah penamaan dan pembolehubah untuk mencerminkan kepelbagaian penamaan.

? Artikel 3: Jangan tulis komen

Anda boleh faham kodnya, kenapa perlu tulis komen? Dengan kata lain, tiada siapa yang membaca kod saya, jadi mengapa saya perlu menulis komen?

? Peraturan 4: Tulis ulasan dalam bahasa ibunda anda

Jika anda melanggar peraturan 3, maka sekurang-kurangnya tulis ulasan dalam bahasa ibunda anda atau bahasa lain. Jika anda seorang penutur asli bahasa Inggeris, anda juga melanggar peraturan ini. Memandangkan kebanyakan bahasa pengaturcaraan adalah dalam bahasa Inggeris, mengapa tidak menggunakan bahasa lain untuk mengulas?

? Perkara 5: Campurkan format yang berbeza sebanyak mungkin

Sekali lagi, untuk kepelbagaian kod, kita perlu mencampurkan format yang berbeza, seperti petikan tunggal atau berganda, sebanyak mungkin. Jika mereka mempunyai semantik yang sama, mereka harus dicampur.

? Perkara 6: Tulis kod dalam satu baris sebanyak mungkin

Jika satu siri parameter dan kaedah dilaksanakan bersama, maka kod itu juga harus ditulis bersama.

?Artikel 7: Berdiam diri apabila anda mendapati ralat Jejak kembali.

?Artikel 8: Gunakan pembolehubah global secara meluas

Menggunakan pembolehubah global adalah bahagian yang sangat diperlukan dalam menghadapi "globalisasi".

? Item 9: Bina pembolehubah sandaran

Untuk berjaga-jaga, kita perlu mencipta beberapa pembolehubah sandaran dan memanggilnya pada bila-bila masa apabila diperlukan.

?Artikel 10: Jenis perlu digunakan dengan berhati-hati

Secara amnya jangan nyatakan jenis pembolehubah atau lakukan semakan taip dengan kerap, tiada jenis adalah jenis yang terbaik.

? Perkara 11: Sediakan "Pelan B"

Anda perlu menyediakan beberapa kod yang tidak boleh dicapai (kod yang tidak boleh dicapai), yang boleh digunakan sebagai "Pelan B" anda.

?Artikel 12: Peraturan Segitiga Bersarang

Jika kod itu mempunyai beberapa struktur bersarang, atau struktur dengan garisan kosong bersarang, Peraturan Segitiga ialah yang paling cantik.

? Artikel 13: Lekukan campuran

Kita perlu mengelak daripada menggunakan lekukan, kerana lekukan akan menjadikan kod kompleks mengambil lebih banyak ruang dalam editor. Jika anda mesti menggunakan lekukan, gunakan strategi lekukan campuran. Sudah tentu, strategi ini tidak berfungsi dalam Python, yang bergantung pada lekukan untuk menstruktur kodnya.

?Artikel 14: Jangan kunci kebergantungan

Setiap kali anda ingin memasang perpustakaan baharu, kemas kini kebergantungan sedia ada. Mengapa mengekalkan versi sebelumnya? Kita perlu menyimpan asas kod pihak ketiga yang terkini pada setiap masa.

?Artikel 15: Fungsi panjang adalah lebih baik daripada fungsi pendek

Jangan bahagikan logik keseluruhan program kepada beberapa blok kod. Jika IDE tiba-tiba gagal, ia tidak dapat mencari fail yang diperlukan atau fungsi apa yang perlu dilakukan. Oleh itu, menulis kod dalam fungsi utama dan tidak lagi mengekalkan import fungsi tambahan atau fail kod adalah kaedah yang paling stabil.

Satu fail dengan 10,000 baris kod tiada masalah, dan satu fungsi dengan seribu baris kod tiada masalah.

?Artikel 16: Kod tidak memerlukan ujian khusus

Ujian ini biasanya kerja berulang dan tidak bermakna.

? Artikel 17: Cuba elakkan kod pendua

Tulis kod mengikut idea anda, terutamanya dalam pasukan kecil, lagipun, ini adalah prinsip "kebebasan".

?Perkara 18: Tiada dokumen README diperlukan untuk membina projek baharu

Pada peringkat awal projek, kita boleh mengekalkan negeri ini buat sementara waktu.

?Artikel 19: Simpan kod yang tidak diperlukan

Dalam proses menulis kod, banyak kod ujian sering dihasilkan. Kod ini juga merupakan maklumat yang sangat penting, jadi ia tidak boleh dipadamkan dan hanya boleh diulas paling banyak.

Atas ialah kandungan terperinci Kod buruk seperti najis, adakah anda menyukainya?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!