Apakah menulis kode mati bermanfaat?

Apakah menurut Anda menulis kode mati bermanfaat?

Beberapa mengatakan "Jika Anda memiliki 2 logika untuk melakukan beberapa operasi maka alih-alih membuat kode logika lain berkomentar atau menghapus kode menjadikannya kode mati karena tidak akan mempengaruhi operasi."

Contoh:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

Apakah itu benar

Saya biasanya tidak menulis kode mati, saya hanya menghapus logika kedua.

IMO, ini lebih buruk daripada sia-sia.

Selain menjadi buang-buang waktu, itu memberi Anda (atau orang berikutnya) ilusi bahwa Anda punya beberapa kode yang akan bekerja jika Anda mengubah trueke false. Itu hanya ilusi ... kecuali Anda mengujinya.

Dan jika tentu saja, itu adalah kekacauan yang membuat kode lebih sulit dibaca.

Jika Anda menggunakan segala jenis kode mati SCM jarang berguna. Anda harus menghapusnya dan jika Anda perlu melihat kode untuk logika 2 Anda mengambilnya dari repositori SCM.

Edit:

Jika Anda memiliki kode mati dan mempertahankan bagian lain dari kode tersebut, Anda dapat mencoba dan menggunakan beberapa kode yang mungkin menghasilkan kode mati. Jika orang lain melakukan pemeliharaan, mereka mungkin tidak tahu kode sebenarnya mati dan bahkan jika mereka melakukannya, mereka pasti tidak akan tahu mengapa itu masih ada.

Jika kemudian Anda menemukan metode yang dapat dihapus karena tidak digunakan oleh kode "langsung" tetapi hanya dengan kode mati, Anda harus mengubah (dan kemungkinan besar menghancurkan) kode mati Anda atau membuat metode lain kode mati itu sendiri.

Pada akhirnya Anda pasti akan berakhir dalam semacam neraka pemeliharaan.

Dengan demikian, kode terbaik adalah kode yang dihapus, karena tidak dapat menghasilkan hasil yang salah atau mengganggu pengelola. :)

Tidak, itu buruk, karena mengacaukan kode Anda dan mengurangi pemeliharaan.

Biasanya, ada alasan yang jelas untuk memilih salah satu dari "logika" alternatif. Alasan ini (dan adanya alternatif yang ditolak) harus didokumentasikan dalam komentar kode. Dalam hal yang relatif tidak mungkin bahwa alasannya menjadi tidak valid, kode alternatif dapat diambil dari riwayat repositori (jika itu yang sebelumnya disukai, solusi yang diimplementasikan), atau disempurnakan dan diimplementasikan menggunakan pengetahuan dan persyaratan penuh saat ini (jika itu hanya samar-samar ide).

Itu tidak mempengaruhi operasi tetapi itu berdampak pada pemeliharaan. Anda ingin menjaga kode serapi mungkin untuk membuatnya lebih mudah untuk dipelihara.

Sejujurnya saya bingung dengan apa yang Anda lakukan.

Dalam urutan prioritas menurun:

1. Anda harus menyimpan catatan perubahan kode di suatu tempat sehingga jika kode baru tidak berfungsi, Anda dapat membandingkannya. Ini harus selalu di kontrol sumber. Saya menganggap Anda sudah melakukan ini. Jika tidak, lakukan semua yang Anda bisa untuk mendapatkan BEBERAPA bentuk kontrol sumber. Jika Anda benar-benar harus melakukannya tanpa (dan saya belum pernah dalam hidup saya mendengar tentang suatu saat ketika ini adalah ide yang baik), setidaknya buat back-up secara teratur keadaan sumbernya dapat diakses.

2. Dengan asumsi Anda melakukan # 1, sehingga Anda dapat memulihkan kode mati jika perlu, JANGAN simpan dalam kode hidup jangka panjang. Itu hanya akan membingungkan, menambah kompleksitas tambahan tanpa nilai, membutuhkan pemeliharaan, tidak sinkron dengan kode langsung dan menyesatkan orang di masa depan, dll, dll.

3. Yang mengatakan, ada situasi tertentu di mana saklar kompilasi waktu antara dua jalur kode masuk akal. Saat Anda sedang mengembangkan kode baru, dan segera setelah itu, mungkin ada baiknya untuk memiliki keduanya, sehingga Anda dapat dengan mudah beralih di antaranya. Jika Anda cenderung harus beralih kembali, atau menambahkan opsi konfigurasi eksternal, jika berdasarkan konstanta memberi mereka jalur peningkatan yang masuk akal. Jadi, seperti banyak hal - jika itu menyelesaikan masalah tertentu, lakukanlah. Jika tidak, hindari.

Alasan saya berasumsi poeple melakukannya terlalu banyak adalah: dari memiliki keraguan (sering kali dengan benar) bahwa orang akan benar-benar membaca sejarah kendali sumber jika mereka memiliki masalah; dari ketakutan kode baru tidak akan berfungsi dan menginginkan opsi pengembalian yang mudah. Suatu kompromi untuk mencoba memenuhi Anda berdua mungkin dengan memberikan komentar "Diubah untuk menghitung ... pada (Tanggal). Jika ada masalah, lihat versi lama di kontrol sumber" atau serupa.

Tidak, ini tidak berguna. Itu elseblok tidak memenuhi tujuan apapun. Jika Anda tidak yakin implementasi mana yang akan digunakan, beri komentar, buat kelas terpisah atau simpan di tempat lain. Juga, sebagian besar Anda memiliki - atau setidaknya harus memiliki - riwayat lokal atau jarak jauh dari file sumber Anda.

Kode mati harus dihapus oleh kompiler jika kondisinya tergantung pada konstanta waktu kompilasi, jadi secara teknis tidak ada salahnya untuk menyimpannya. Namun saya lebih suka berkomentar karena ini meningkatkan keterbacaan kode.

Jika Anda ingin dapat dengan cepat beralih di antara dua alternatif kode, Anda dapat menggunakan susunan komentar praktis berikut:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

jika Anda hanya menghapus yang pertama /di baris komentar pertama menjadi:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

Dengan ini, Anda dapat beralih di antara alternatif dengan hanya menambahkan atau menghapus satu /di kode.

Ini mungkin terlihat agak aneh pada awalnya, tetapi begitu Anda terbiasa, Anda akan dengan mudah mengenalinya sebagai semacam pola.

Anda bahkan dapat rantai ini dan dengan demikian beralih beberapa blok sekaligus dengan satu karakter:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

Saya tidak akan menggunakannya dengan cara ini tetapi berhasil.

Ada beberapa kesempatan yang sangat langka ketika kode lama, dan fakta bahwa itu sudah diganti, benar-benar harus tetap dalam kode sumber sehingga programmer masa depan diperingatkan tentang sesuatu yang kontra-intuitif. Dalam hal ini, perlu juga ada semacam komentar yang menjelaskan mengapa itu masih ada dan apa yang terjadi.

Seperti biasa, menulis program yang mudah dipelihara adalah membuat segalanya menjadi lebih jelas, tidak hanya mengikuti aturan yang keras dan cepat. Jika meninggalkan kode mati membuatnya lebih mudah untuk memahami apa yang terjadi, maka tinggalkan. Jika tidak, maka keluarkan.

Itu akan diabaikan oleh kompiler. Namun saya setuju dengan Anda dan hanya akan menghapus pernyataan yang lain. Dengan asumsi Anda menggunakan kontrol versi, Anda masih dapat melihat kode lama dengan melihat riwayat file.

Ini mungkin pendapat pribadi, tetapi saya menemukan kode mati mengganggu ketika mempertahankan sepotong kode. Untuk setiap tugas yang diberikan, Anda selalu memiliki lebih dari satu cara untuk menyelesaikannya, jadi Anda harus memilih satu. Lakukan riset, evaluasi algoritme, dan pilih satu. Setelah ini, kode tidak perlu mengandung metode alternatif apa pun di dalamnya.

Jika ada dua pesaing yang sangat kuat, tulis catatan kecil tentang alternatifnya, dan tempel di wiki proyek, atau di tempat lain yang berisi dokumentasi proyek. Jika Anda ingin, Anda dapat memberikan komentar satu baris yang merujuk pada dokumen ini, dan menguraikan mengapa Anda ingin membacanya.

Saya tidak dapat segera memikirkan situasi di mana saya menemukan penulisan kode mati bermanfaat. Jika ada algoritma alternatif, maka:

• baik Anda menyimpan yang paling berguna dan menghilangkan yang lain,
• atau algoritma yang berlaku untuk keadaan yang berbeda, dan kemudian Anda menjaga keduanya dan kondisi mengidentifikasi situasi saat Anda menggunakan algoritma pertama.

Dalam kedua kasus, Anda berakhir tanpa kode mati.

Jika Anda tidak menghapus atau mengomentari kode mati Anda, Anda harus mempertahankannya untuk menghindari kesalahan kompiler. Ini buang-buang waktu. Hapus saja jika Anda memiliki SCM.

TIDAK

Beberapa programmer menggunakan gaya ini sebagai alternatif untuk komentar dan menganggapnya elegan.

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

Jawaban sederhananya adalah tidak. Kode mati menarik kebingungan, dan peluang terjadinya bug. Segera setelah Anda mengetikkan karakter ke dalam kode, ada risiko. Jadi jangan menambahkan lebih dari yang seharusnya.

Satu kali saya harus menulis sesuatu yang serupa adalah sebagai penyelesaian untuk bug kompiler, bahkan direkomendasikan oleh vendor kompiler untuk menggunakan pekerjaan ini.

Apakah Anda menguji kode mati yang Anda tulis? Lakukan sesuatu untuk mengonfirmasi bahwa itu mungkin baik? Jika tidak, singkirkan.

Untuk perubahan kode di masa mendatang, apakah Anda akan memverifikasi bahwa kode mati masih berfungsi? Jika tidak, singkirkan.

Anda tidak ingin kode buruk dalam program Anda, bahkan jika itu tidak digunakan. Setelah itu di sana menunjukkan bahwa itu dapat digunakan. Anda biasanya tidak ingin mempertahankan dua versi kode jika Anda tidak menggunakan keduanya, karena ini adalah pekerjaan tambahan, dan karena rasanya tidak ada gunanya kebanyakan orang tidak akan melakukan pekerjaan dengan baik pada kode yang mati.

Mungkin ada alasan untuk menjaga kode yang dikomentari (atau, dalam C atau C ++, #ifdefkode ed out), tetapi ini harus disertai dengan komentar mengapa itu masih ada dan tujuan apa yang dilayaninya.

Perhatikan bahwa di Jawa, yang berikut ini bahkan tidak dapat dikompilasi, karena kode yang tidak terjangkau:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

Idealnya, jika ada sesuatu yang salah dengan kode Anda, Anda ingin menemukannya sedini mungkin, daripada membiarkannya diproduksi dan ditemukan oleh pengguna Anda.

Jika kelas kesalahan dapat ditemukan oleh kompiler Anda, maka biarkan kompiler menemukannya. IMHO, apa yang dilakukan seseorang dengan menulis kode mati dengan cara yang Anda jelaskan, sedang berusaha untuk menghindari kesalahan kompiler itu, yang memungkinkan masalah apa pun yang mungkin menyebabkannya muncul saat runtime.

Anda mungkin berpendapat bahwa kode mati tidak dapat dihubungi, jadi tidak dapat menyebabkan masalah, tetapi ada yang salah dalam berkomentar, menguatkan, dan lekukan yang mungkin membuatnya terjadi.

Alasan mengapa orang berkomentar beberapa logika lama adalah karena mereka takut membuat perubahan besar pada kode. Dan memang, menyadari seminggu kemudian bahwa kode lama sebenarnya benar dan sekarang Anda harus menulisnya dari awal adalah menyebalkan. Tapi untuk itulah kontrol sumber. Jika Anda memutuskan untuk mengubah beberapa logika, jangan takut kehilangan kode present yang berfungsi. Hapus dan biarkan SVN / Git / TFS Anda mengurus versi untuk Anda.

Jika bukan itu masalahnya dan Anda hanya menghasilkan dua bagian logika yang berbeda untuk melakukan sesuatu karena Anda tidak peduli dengan YAGNI atau KERING, maka pastikan Anda meletakkannya di tempat di mana orang dapat menggunakannya. Mungkin melempar pola strategi di sana jika Anda suka. Hanya saja, jangan lakukan hal-hal "jika ... yang lain", ini desain yang buruk dan sulit untuk dipertahankan. Jika Anda benar-benar berpikir bahwa beberapa kode memiliki hak untuk ada, pastikan Anda membuatnya mungkin untuk menggunakannya.

Pandangan lain adalah bahwa pada dasarnya kebanyakan programmer profesional setuju bahwa ukuran kode adalah musuh. Lihatlah posting blog ini: Kode terbaik adalah tidak ada kode sama sekali oleh Jeff Atwood, musuh terburuk Code oleh Steve Yegge, Anda dapat menemukan lebih banyak lagi.

Orang-orang melakukan banyak hal untuk menjaga kode mereka singkat dan mencegah basis kode menjadi terlalu besar, seringkali bahkan dengan mengorbankan kinerja (di mana itu tidak terlalu menjadi masalah). Jadi, apakah Anda benar-benar berpikir bahwa 100 baris kode mati dapat menjadi hal yang baik?

Satu-satunya tempat saya telah melihat ini menjadi berguna adalah dalam kasus di mana Anda ingin dengan cepat menonaktifkan sesuatu dan menguji / mengisi ulang (katakanlah program melakukan langkah A, B, C - semua membutuhkan waktu lama. Selama pengisian ulang, Anda mungkin memilih untuk menonaktifkan B dan C untuk sementara waktu untuk mempercepatnya jika Anda tahu mereka tidak perlu).
Tetapi kenyataannya adalah bahwa dalam semua kasus ini sangat berantakan. Dan jika Anda melihat penggunaan jangka panjang untuk kode pengisian ulang Anda, Anda harus menulis kode Anda sedemikian rupa sehingga menggunakan konfigurasi untuk memilih pilihan daripada menggunakan peretasan seperti itu.
Aturan praktis saya adalah bahwa jangan pernah checkin kode semacam ini. Jika Anda memerlukan kontrol checkin / versi, itu berarti Anda akan dapat kembali ke ini dalam waktu dekat, dan itu selalu merupakan hal yang buruk mengingat perubahan persyaratan.

Sebenarnya, ada satu cara yang berguna untuk memiliki kode "mati": ketika Anda ingin program Anda melempar pengecualian besar karena mencapai sesuatu yang seharusnya tidak pernah terjadi. Ini bisa berupa kesalahan kompiler, atau jika seseorang di telepon mengubah logika dalam tes yang Anda gunakan, dan mengacaukannya. Either way, "lain" Anda mengirimkan kembang api. Dalam hal ini, Anda ingin membatalkannya untuk rilis.

Sangat penting bahwa pesan kesalahan menyatakan sesuatu seperti "Panic: kita tidak seharusnya berada di sini pada baris% d dalam file% s" ...