Orang, pada dasarnya, cenderung membuat kesalahan. Namun, banyak kekurangan khusus untuk pengembang dapat dihindari. Jika seorang programmer dapat menyingkirkan kesalahan umum yang akan dibahas dalam artikel ini, ia akan dapat menulis kode yang lebih baik dan lebih bersih.
Menghilangkan kekurangan dalam kode tidak hanya akan menguntungkan mereka yang menyingkirkannya, tetapi juga para programmer yang harus membaca kode ini. Sebagai hasilnya, kita dapat mengatakan bahwa mereka yang bekerja dalam tim dan berusaha untuk memperbaiki kode mereka melakukan ini tidak hanya untuk diri mereka sendiri, tetapi juga untuk mereka yang bekerja dengan mereka.
Berikut adalah beberapa kelemahan umum yang harus dihindari oleh seorang programmer.
1. Terlalu banyak aksi dalam fungsi
Sesuai dengan prinsip satu-satunya tanggung jawab, suatu fungsi harus bertanggung jawab hanya untuk kinerja setiap operasi. Dan ini seharusnya hanya satu operasi. Saya melihat terlalu banyak fungsi yang melakukan pemuatan, pemrosesan, dan penyajian data tertentu. Diyakini bahwa implementasi dari tindakan-tindakan semacam itu paling baik didistribusikan di antara beberapa fungsi. Satu fungsi memuat data, proses lain, yang ketiga bertanggung jawab atas presentasinya.
Alasan pentingnya fungsi penulisan yang berfokus pada penyelesaian satu masalah adalah bahwa pendekatan ini membuat kode lebih dapat diandalkan. Misalkan dalam kasus di atas, data dimuat dari API tertentu. Jika API ini berubah, misalnya, jika versi baru dirilis, maka sangat mungkin bahwa seluruh fungsi akan berhenti berfungsi. Kode yang memuat data akan memuat sesuatu yang salah, ini akan memengaruhi pemrosesan dan penyajian data. Untuk menyelesaikan masalah, pertama-tama Anda harus menemukannya, mencari tahu apa yang gagal, dan kemudian mengedit kode fungsi yang besar. Jika pemuatan, pemrosesan, dan penyajian data dibagi menjadi beberapa fungsi, akan lebih mudah untuk menyelesaikan masalah tersebut.
2. Proyek memiliki kode komentar
Semua orang melihat kode, fragmen besar yang, misalnya, berisi fungsi tertentu, dikomentari. Namun, tidak ada yang tahu mengapa fragmen ini masih belum dihapus dari basis kode. Dan tidak ada yang tahu apakah potongan-potongan kode ini akan berfungsi jika tidak diomortasikan. Tetapi pada saat yang sama mereka tidak dihapus. Dan Anda harus menghapusnya. Alasan kode ini mencemari proyek adalah karena semua orang menyarankan seseorang mungkin membutuhkan kode ini.
Fragmen kode seperti itu harus dihapus begitu saja. Dan jika dalam versi terbaru kode fragmen-fragmen jarak jauh ini tidak ada, dan pada saat yang sama seseorang benar-benar membutuhkannya, mereka dapat ditemukan dalam sistem kontrol versi. Saya perhatikan bahwa ini hanya pendapat saya tentang masalah ini.
3. Nama variabel buruk
Suatu hari saya menulis
sebuah artikel yang menyajikan aturan sederhana untuk memilih nama variabel yang baik. Nama variabel kualitatif sangat penting. Faktanya adalah bahwa programmer biasanya tidak mengerjakan proyek sendirian. Rekan-rekan mereka perlu memahami kode yang mereka tulis. Nama variabel yang ramah membantu meningkatkan persepsi kode orang lain.
Saya ulangi apa yang saya katakan dalam materi di atas: "Memilih nama variabel yang baik membutuhkan waktu, tetapi menghemat lebih banyak waktu daripada yang dibutuhkan."
4. "Angka ajaib" dan string
Jika kita melanjutkan diskusi kita tentang masalah nama variabel yang tidak jelas, kita bisa sampai pada ide untuk menggunakan nilai-nilai tertentu dalam program, "angka ajaib" atau string yang tidak memiliki nama sama sekali dan tidak ditulis ke variabel apa pun.
Anda dapat belajar dari
Wikipedia bahwa "angka ajaib" disebut praktik pemrograman yang buruk ketika nilai numerik ditemukan dalam teks sumber dan tidak jelas apa artinya.
Lihatlah contoh kode berikut:
for ($i = 1; $i <= 52; $i++) { ... }
Di sini nilai
52 adalah "angka ajaib". Tidak ada yang tahu mengapa ini persis nomor 52, dan apa artinya. Mengapa 52 Kenapa tidak 64? Mungkin ini jumlah minggu dalam setahun?
Kode ini akan menjadi lebih jelas jika Anda menulis ulang seperti ini:
$cardDeckSize = 52; for ($i = 1; $i <= $cardDeckSize; $i++) { ... }
Sekarang siapa pun akan mengerti bahwa dalam satu siklus kita melewati setumpuk kartu. Ini menunjukkan kepada pengembang lain esensi dari apa yang terjadi, membantu memahami konteks tindakan yang dilakukan. Pendekatan ini, di samping itu, sangat menyederhanakan perubahan nilai ini, karena itu, jika digunakan di tempat yang berbeda dari program, diatur hanya di satu tempat dalam kode.
Hal yang sama berlaku untuk bekerja dengan string:
if (userPasswordIsValid($user, "6yP4cZ".$password)) { ... }
Apa ini
6yP4cZ ? Sepertinya set karakter acak.
Kami menulis ulang ini:
$salt = "6yP4cZ"; if (userPasswordIsValid($user, $salt.$password)) { ... }
Tapi sekarang semuanya jauh lebih jelas.
5. Pemformatan kode yang tidak akurat
Pemformatan kode yang tidak rapi adalah "penyakit" bagi pemrogram pemula. Banyak pengembang dengan beberapa pengalaman cenderung mengangguk setuju ketika ditanya apakah mereka tahu seorang penguji atau ilmuwan data yang tidak memformat kode dengan baik. Alasannya adalah karena kurangnya pengalaman. Satu-satunya pengecualian adalah pemrogram yang menggunakan bahasa seperti Python, di mana pemformatan kode memengaruhi eksekusi program.
Salah satu cara paling umum untuk menyelesaikan masalah ini adalah dengan menggunakan linter. Semua IDE modern, di samping itu, mendukung kemampuan untuk memformat kode secara otomatis. Terkadang fungsi ini diimplementasikan melalui plugin yang harus Anda instal sendiri, dan kadang-kadang termasuk dalam fitur IDE standar.
6. Nilai-nilai dalam kode keras
Jika nilai-nilai tersebut dikodekan ke dalam program, ini berarti bahwa data disematkan secara langsung dalam kode sumber atau objek serupa lainnya. Kebalikan dari pendekatan ini adalah memperoleh data dari sumber eksternal atau menghasilkannya selama pelaksanaan program.
Nilai-nilai hard-set tidak memungkinkan konfigurasi program yang mudah. Jadi, begitulah, "diukir di atas batu." Ini dianggap sebagai anti-pola, atau, setidaknya, menunjukkan masalah yang jelas dalam kode.
Paling sering, kata sandi dan jalur file di-hardcode. Mereka melakukan ini karena berbagai alasan, terkadang mereka bahkan dapat dibenarkan.
Misalnya, banyak nilai kode keras dapat dilihat dalam beberapa contoh kode yang bertanggung jawab untuk otentikasi pada layanan eksternal atau API. Lebih baik tidak melakukannya.
Jika seseorang memperhatikan seringnya menggunakan nilai yang di-hardcode, ia harus mengevaluasi pekerjaannya secara kritis. Faktanya adalah bahwa biasanya penggunaan nilai-nilai tersebut bukan cara terbaik untuk memecahkan masalah tertentu.
Pembaca yang budiman! Apa kekurangan dalam kode yang Anda temui?
