10 tabiat pengaturcaraan buruk yang kita gemari secara diam-diam

Kita semua berjaya: membakar kuki ketika ibu tidak mencari, minum terlalu banyak wain untuk makan malam, membiarkan kereta duduk di tempat letak kereta setelah meter habis. Kita terlalu cepat melihat Deadman's Curve. Dan ya, kita semua telah melanggar sejumlah peraturan kardinal pengaturcaraan, yang mana semua orang setuju adalah buruk. Dan kami diam-diam menyukainya.

Kami telah memahami peraturan pengaturcaraan yang baik, menaip kod yang benar-benar buruk - dan kami telah menjalani. Tidak ada petir dari dewa pengaturcaraan. Desktop kami tidak meletup. Sebenarnya, kod kami disusun dan dihantar, dan pelanggan kelihatan cukup gembira.

Itu kerana pengaturcaraan yang buruk tidak sama dengan, katakanlah, menjilat pagar elektrik atau menarik ekor harimau. Selalunya, ia berjaya. Peraturannya lebih kerap merupakan panduan atau cadangan gaya, bukan arahan keras dan cepat yang mesti dipatuhi atau kod kematian akan dipatuhi. Pasti, kod anda mungkin diejek, bahkan mungkin secara terbuka. Tetapi hakikat bahawa anda membuat konvensyen menambah sedikit keseronokan untuk menumbangkan, bahkan secara tidak sengaja, apa yang berjumlah (lebih kerap daripada tidak) kebiasaan sosial kod yang menyenangkan.

Untuk menjadikan perkara lebih rumit, kadang-kadang lebih baik melanggar peraturan. (Shhhh!) Kodnya lebih bersih. Ia mungkin lebih pantas dan sederhana. Peraturannya biasanya terlalu luas, dan pengaturcara yang cekap dapat memperbaiki kod dengan melanggarnya. Jangan beritahu bos anda, tetapi kadang-kadang masuk akal untuk membuat kod dengan cara anda sendiri.

Yang berikut adalah senarai sembilan peraturan yang mungkin dianggap tidak dapat dilaksanakan oleh mereka, tetapi banyak di antara kita sering melanggar, dengan kejayaan dan kesenangan.

Kebiasaan pengaturcaraan yang buruk No. 1: Menyalin 

Ia salah untuk melakukannya di sekolah. Di tempat kerja, peraturannya tidak begitu jelas. Sudah tentu ada beberapa blok kod yang tidak boleh dicuri. Sekiranya ia berasal dari kod proprietari, jangan lipat ke dalam timbunan anda, terutama jika ditandai dengan mesej hak cipta. Tulis versi anda sendiri. Itulah yang mereka bayar untuk anda lakukan.

Soalan yang lebih sukar timbul apabila pencipta asal ingin berkongsi. Mungkin itu adalah salah satu forum pengaturcaraan dalam talian. Mungkin ia adalah kod sumber terbuka dengan lesen (BSD, MIT) yang membenarkan fungsi atau tiga fungsi tersembunyi. Tidak ada alasan undang-undang untuk menghentikan anda. Dan anda dibayar untuk menyelesaikan masalah, bukan mencipta semula roda.

Sebilangan besar masa, kelebihan menyalin sangat menarik dan keburukannya dapat dibatasi dengan sedikit perhatian. Kod yang anda dapatkan dari sumber yang bereputasi sudah memiliki sekurang-kurangnya satu putaran pemikiran yang diterapkan padanya. Pengarang asal mencari jalan penyelesaian dan menemui sesuatu. Inovarian gelung dan aliran data telah diselesaikan.

Soalan yang sukar adalah sama ada terdapat bug yang tidak berasas atau beberapa andaian yang berbeza mengenai peranan atau data yang mendasari. Mungkin kod anda bercampur dengan penunjuk kosong sedangkan kod asal tidak pernah memeriksanya. Sekiranya anda dapat menyelesaikan masalah, sepertinya bos anda mendapat input daripada dua pengaturcara. Ia adalah pengaturcaraan pasangan tanpa meja mewah.

Kebiasaan pengaturcaraan yang buruk No. 2: Kod tidak berfungsi

Selama satu dekad yang lalu, paradigma fungsional telah meningkat. Pembantu untuk membina program anda daripada panggilan fungsi bersarang suka mengutip kajian yang menunjukkan bagaimana kodnya lebih selamat dan bebas bug daripada gaya pemboleh ubah dan gelung yang lebih lama, semuanya digabungkan bersama dengan cara apa pun yang menjadikan pengaturcara gembira. Para penyembah berbicara dengan semangat orang-orang percaya sejati, menghukum pendekatan yang tidak berfungsi dalam tinjauan kod dan permintaan menarik. Mereka mungkin betul mengenai kelebihannya.

Tetapi kadang-kadang anda hanya perlu mengeluarkan sebatang pita saluran. Kod yang dirancang dengan baik dan dirancang dengan baik memerlukan masa, bukan hanya untuk membayangkan tetapi juga untuk membina dan kemudian untuk menavigasi. Semua lapisan itu menambah kerumitan, dan kerumitan itu mahal. Pembangun kod fungsional yang indah perlu merancang lebih awal dan memastikan semua data dihantar melalui jalan yang betul. Kadang-kadang lebih mudah untuk menjangkau dan menukar pemboleh ubah. Mungkin masukkan komen untuk menerangkannya. Bahkan dengan menambahkan permintaan maaf yang panjang lebar untuk generasi akan datang dalam komen lebih pantas daripada membina semula keseluruhan sistem untuk melakukannya dengan cara yang betul.

Kebiasaan pengaturcaraan yang buruk No. 3: Jarak yang tidak standard

Sebilangan besar ruang dalam perisian tidak berpengaruh pada prestasi program. Kecuali untuk beberapa bahasa seperti Python yang menggunakan jarak untuk menunjukkan blok kod, kebanyakan ruang tidak memberi kesan pada bagaimana program tersebut berkelakuan. Namun, ada programmer obsesif yang menghitungnya dan menegaskan bahawa mereka penting. Salah seorang dari mereka pernah memberitahu bos saya dengan nada yang paling serius bahawa saya sedang menulis "Non Standard Code" dan dia dapat melihatnya dengan segera. Dosa saya? Melanggar peraturan ESLint space-infix-ops dengan gagal meletakkan ruang di kedua sisi tanda sama.

Kadang-kadang anda hanya perlu memikirkan sesuatu yang lebih mendalam daripada penempatan ruang. Mungkin anda bimbang pangkalan data bertambah. Mungkin anda bimbang tentang cara penunjuk kosong boleh merosakkan kod anda. Sebilangan besar bahagian kod ini lebih penting daripada spasi, walaupun jawatan kosong, jawatankuasa piawai telah mengisi halaman peraturan mengenai penempatan ruang atau tab ini.

Yang mengagumkan ialah terdapat beberapa alat yang baik yang secara automatik akan memformat semula kod anda untuk mematuhi peraturan peletakan yang ditentukan dengan baik. Manusia tidak perlu meluangkan masa memikirkan perkara ini. Sekiranya sangat penting, mereka dapat menjalankannya melalui alat untuk membersihkan masalahnya.

Kebiasaan pengaturcaraan yang buruk No. 4: Menggunakan goto

Larangan menggunakan gototarikh hingga era sebelum banyak alat pengaturcaraan berstruktur bahkan ada. Sekiranya pengaturcara ingin membuat gelung atau melompat ke rutin lain, mereka perlu menaip GOTOdiikuti dengan nombor garis. Selepas beberapa tahun, pasukan penyusun membiarkan pengaturcara menggunakan label rentetan dan bukannya nombor garis. Itu dianggap sebagai ciri baru yang panas ketika itu.

Ada yang menyebut hasilnya "kod spageti." Tidak mungkin sesiapa membaca kod anda kemudian dan mengikuti jalan pelaksanaannya. Itu adalah jalinan benang, selamanya kusut. Edsger Dijkstra melarang perintah itu dengan manuskrip berjudul "Pernyataan Goto Dianggap Berbahaya."

Tetapi percabangan mutlak bukanlah masalahnya. Inilah kekusutan yang terhasil. Selalunya berseni breakatau returnakan memberikan pernyataan yang sangat bersih tentang apa yang dilakukan kod di lokasi tersebut. Kadang kala penambahan gotopada pernyataan kes akan menghasilkan sesuatu yang lebih mudah difahami daripada senarai tersusun yang lebih tepat sekiranya blok jika-kemudian-lain.

Terdapat banyak contoh. Lubang keselamatan "goto fail" dalam timbunan SSL Apple adalah salah satu contoh terbaik. Tetapi jika kita berhati-hati untuk mengelakkan sebilangan masalah pernyataan kes dan gelung, kita boleh memasukkan lompatan mutlak yang baik yang memudahkan pembaca memahami apa yang berlaku. Kita dapat memasukkan breakatau returnlebih bersih atau menyenangkan bagi semua orang - kecuali mungkin gotopembencinya.

Kebiasaan pengaturcaraan yang buruk No. 5: Tidak menyatakan jenis

Orang-orang yang suka bahasa yang ditaip mempunyai maksud. Kami menulis kod yang lebih baik dan bebas bug apabila kami menambahkan pernyataan yang jelas mengenai jenis data setiap pemboleh ubah. Menjeda sebentar untuk menguraikan jenis ini membantu penyusun bendera kesilapan bodoh sebelum kod mula berjalan. Ia mungkin menyakitkan, tetapi ia sangat membantu. Ini adalah pendekatan belts-and-suspenders untuk pengaturcaraan yang menghentikan pepijat.

Masa telah berubah. Sebilangan besar penyusun baru cukup pintar untuk membuat kesimpulan dengan melihat kodnya. Mereka boleh bekerja ke belakang dan maju melalui kod sehingga mereka dapat memastikan bahawa pemboleh ubah mestilah stringatau intatau sesuatu yang lain. Dan jika jenis kesimpulan ini tidak berbaris, maka penyusun dapat menaikkan bendera kesalahan. Mereka tidak memerlukan kita untuk menaip pembolehubah lagi.

Ini bermaksud sekarang lebih mudah untuk menjimatkan beberapa bit dengan meninggalkan beberapa deklarasi termudah. Kod menjadi sedikit lebih bersih, dan pembaca biasanya dapat meneka bahawa pemboleh ubah yang dinamakan idalam untuk gelung adalah bilangan bulat.

Kebiasaan pengaturcaraan yang buruk No. 6: Kod Yo-yo

Pengaturcara suka menyebutnya "kod yo-yo." Mula-mula nilai disimpan sebagai rentetan. Kemudian mereka dihuraikan menjadi bilangan bulat. Kemudian mereka kembali menjadi rentetan. Ia sangat tidak cekap. Anda hampir dapat merasakan perjuangan CPU di bawah semua beban tambahan. Pengaturcara pintar yang menulis kod pantas merancang seni bina mereka untuk meminimumkan penukaran. Kod mereka berjalan lebih cepat kerana perancangan mereka.

Tetapi percaya atau tidak, kadang-kadang masuk akal. Kadang kala anda mempunyai perpustakaan jagoan yang melakukan banyak perkara pintar di dalam kotak hitam miliknya. Kadang-kadang bos menulis cek tujuh angka untuk melesenkan semua genius di dalam kotak hitam itu. Sekiranya pustaka menginginkan data dalam rentetan, anda memberikannya kepada perpustakaan dalam rentetan walaupun anda baru menukarnya menjadi bilangan bulat.

Pasti, anda boleh menulis semula semua kod anda untuk meminimumkan penukaran, tetapi memerlukan masa. Kadang kala OK untuk menjalankan kod minit, jam, hari, atau bahkan seminggu kerana menulis semula kod akan memerlukan lebih banyak masa. Kadang kala menguruskan hutang teknikal lebih murah daripada membaginya dengan betul.

Kadang kala perpustakaan bukan kod proprietari, tetapi kod yang anda tulis sendiri dahulu. Kadang-kadang lebih pantas menukar data sekali lagi daripada menulis semula semua yang ada di perpustakaan itu. Oleh itu, anda teruskan dan anda menulis kod yo-yo. Tidak apa-apa - kita semua pernah ke sana.

Kebiasaan pengaturcaraan yang buruk No. 7: Menulis struktur data anda sendiri

Salah satu peraturan standard adalah bahawa programmer tidak boleh menulis kod untuk menyimpan data setelah menyelesaikan kursus struktur data pada tahun kedua mereka. Orang lain telah menulis semua struktur data yang kita perlukan, dan kodnya telah diuji dan diuji semula selama bertahun-tahun. Ia digabungkan dengan bahasa dan mungkin percuma. Kod anda hanya boleh mengandungi pepijat.

Tetapi kadang-kadang perpustakaan struktur data agak perlahan. Kadang-kadang mereka memaksa kita menjadi struktur yang mungkin standard tetapi salah untuk kod kita. Kadang-kadang perpustakaan mendorong kita untuk mengkonfigurasi ulang data kita sebelum kita menggunakan strukturnya. Kadang-kadang perpustakaan merangkumi pelindung tali pinggang dan suspender dengan ciri seperti mengunci utas, dan kod kami tidak memerlukannya.

Apabila itu berlaku, sudah waktunya untuk menulis struktur data kita sendiri. Kadang-kadang ia jauh lebih cepat. Dan kadangkala menjadikan kod kita jauh lebih bersih kerana kita tidak memasukkan semua kod tambahan untuk memformat semula data dengan tepat.

Kebiasaan pengaturcaraan yang buruk No. 8: Gelung kuno

Lama dahulu, seseorang yang mencipta bahasa C ingin merangkum semua kemungkinan abstrak dalam satu konstruk sederhana. Terdapat beberapa perkara yang harus dilakukan pada awalnya, beberapa perkara yang harus dilakukan setiap kali melalui gelung, dan beberapa cara untuk mengetahui kapan semuanya selesai. Pada masa itu, sepertinya sintaks yang sangat bersih untuk menangkap kemungkinan yang tidak terhingga.

Itu ketika itu. Sekarang beberapa teguran moden hanya melihat masalah. Terlalu banyak perkara yang berlaku. Semua kemungkinan kebaikan itu juga sama dengan keburukan. Ini menjadikan membaca dan merotan menjadi lebih sukar. Mereka menyukai paradigma yang lebih berfungsi di mana tidak ada gelung, hanya fungsi yang diterapkan pada senarai, templat komputasi yang dipetakan ke beberapa data.

Ada kalanya cara tanpa gelung lebih bersih, terutama ketika hanya ada satu fungsi dan susunan yang rapi. Tetapi ada kalanya gelung kuno jauh lebih mudah kerana dapat melakukan lebih banyak lagi. Sebagai contoh, mencari perlawanan pertama lebih mudah apabila anda boleh berhenti sebaik sahaja ia dijumpai.

Tambahan pula, fungsi pemetaan mendorong pengekodan sloppier apabila terdapat banyak perkara yang harus dilakukan terhadap data. Bayangkan anda mahu mengambil nilai mutlak dan kemudian punca kuasa dua nombor. Penyelesaian terpantas adalah memetakan fungsi pertama dan kemudian yang kedua, mengulangi data dua kali. 

Kebiasaan pengaturcaraan yang buruk No. 9: Melepaskan gelung di tengah

Di suatu tempat, kumpulan pembuat peraturan menyatakan bahawa setiap gelung harus mempunyai "invarian", yang bermaksud pernyataan logik yang benar sepanjang gelung. Apabila invarian tidak lagi benar, gelung berakhir. Ini adalah cara yang baik untuk memikirkan gelung yang kompleks, tetapi ia membawa kepada larangan gila — seperti melarang kita menggunakan a returnatau a breakdi tengah gelung. Ini adalah subset peraturan yang melarang gotopenyataan.

Teori ini baik, tetapi biasanya membawa kepada kod yang lebih kompleks. Pertimbangkan kes mudah ini yang mengimbas array untuk satu entri yang lulus ujian:

Sementara saya
   
    

   ...

   jika (ujian (a [i]) kemudian kembalikan [i];

   ...

}

Pencinta loop invarian lebih suka kita menambahkan pemboleh ubah boolean lain, memanggilnya notFound, dan menggunakannya seperti ini:

sementara ((notFound) && (i
   
    

...

jika (ujian (a [i])) maka notFound = false;

...

}

Sekiranya boolean ini disebut dengan baik, ia adalah kod pendokumentasian diri yang bagus. Mungkin memudahkan semua orang memahami. Tetapi ia juga menambahkan kerumitan. Dan ini bermaksud memperuntukkan pemboleh ubah tempatan yang lain dan menyumbat daftar yang mungkin atau tidak mungkin disusun oleh penyusun yang cukup pintar.

Kadang-kadang a gotoatau lompatan lebih bersih.

Kebiasaan pengaturcaraan yang buruk No. 10: Mentakrifkan semula operator dan fungsi

Beberapa bahasa yang paling menyeronokkan membolehkan anda melakukan perkara yang benar-benar licik seperti mentakrifkan semula nilai elemen yang kelihatannya tetap. Python, misalnya, membolehkan anda menaip TRUE=FALSE, sekurang-kurangnya dalam Versi 2.7 dan sebelumnya. Ini tidak menimbulkan semacam keruntuhan logik dan akhir alam semesta; ia hanya menukar makna TRUEdan FALSE. Anda juga boleh bermain permainan berbahaya seperti ini dengan preprocessor C dan beberapa bahasa lain. Bahasa lain masih membolehkan anda mentakrifkan semula operator seperti tanda tambah.

Ini adalah peregangan, tetapi akan ada titik dalam sekatan besar apabila lebih pantas untuk mentakrifkan semula satu atau lebih daripada yang disebut pemalar ini. Kadang-kadang bos mahu kod melakukan sesuatu yang sama sekali berbeza. Pasti, anda boleh menggunakan kod tersebut dan mengubah setiap kejadian, atau anda boleh menentukan semula kenyataan. Ia boleh membuat anda kelihatan seperti seorang genius. Daripada menulis semula perpustakaan yang besar, anda hanya membalikkan sedikit dan sebaliknya.

Mungkin bagus untuk menarik garis di sini. Anda tidak boleh mencuba ini di rumah, tidak kira seberapa pintar dan seronoknya. Ini terlalu berbahaya - sungguh ... jujur.