Haruskah sintaks untuk menonaktifkan kode berbeda dari komentar normal?

8

Untuk beberapa alasan selama pengembangan, saya terkadang berkomentar keluar kode. Karena saya kacau dan kadang-kadang terburu-buru, beberapa di antaranya membuatnya menjadi kontrol sumber.

Saya juga menggunakan komentar untuk memperjelas blok kode.

Contohnya:

MyClass MyFunction()
{
    (...)
    // return null; // TODO: dummy for now
    return obj;
}

Meskipun "berfungsi" dan banyak orang melakukannya dengan cara ini, saya kesal karena Anda tidak dapat secara otomatis membedakan kode komentar dengan komentar "nyata" yang memperjelas kode:

itu menambah kebisingan ketika mencoba membaca kode
Anda tidak dapat mencari kode yang dikomentari untuk misalnya hook on-commit dalam kontrol sumber.

Beberapa bahasa mendukung banyak gaya komentar baris tunggal - misalnya dalam PHP Anda dapat menggunakan //atau #untuk komentar baris tunggal - dan pengembang dapat sepakat untuk menggunakan salah satu dari ini untuk kode komentar:

# return null; // TODO: dummy for now
return obj;

Bahasa lain - seperti C # yang saya gunakan hari ini - memiliki satu gaya untuk komentar single-line (kan? Saya berharap saya salah). Saya juga telah melihat contoh kode "commenting-out" menggunakan arahan kompiler, yang bagus untuk blok kode besar, tetapi sedikit berlebihan untuk satu baris karena dua baris baru diperlukan untuk arahan:

#if compile_commented_out
    return null; // TODO: dummy for now
#endif
return obj;

Jadi, ketika kode komentar terjadi dalam setiap (?) Bahasa, bukankah seharusnya "kode yang dinonaktifkan" mendapatkan sintaksnya sendiri dalam spesifikasi bahasa? Apakah pro (pemisahan komentar / kode yang dinonaktifkan, editor / kontrol sumber bertindak atas mereka) cukup baik dan kontra ("toh tidak boleh melakukan commenting-out", bukan bagian fungsional dari bahasa, potensi keterlambatan IDE (terima kasih Thomas )) layak dikorbankan?

Edit

Saya menyadari contoh yang saya gunakan adalah konyol; kode dummy dapat dengan mudah dihapus karena diganti dengan kode yang sebenarnya.

comments syntax

— deltreme
sumber

Saya tidak melihat ada yang salah dengan ini - mengomentari dan menghapus komentar dari blok kode kecil kadang-kadang merupakan taktik yang berguna untuk men-debug bug yang sangat spesifik di basis kode legacy yang besar. Saya menemukan ini membantu saya mempersempit masalah (selain menggunakan debugger yang tepat, tentu saja). Saya tidak keberatan melihat tipe khusus dari komentar, mungkin /# ... #/itu akan menyoroti berbeda dalam IDE (untuk isyarat visual) dan mungkin menghasilkan compiler peringatan yang kemudian akan terjebak dan dilaporkan oleh membangun malam jika seseorang tidak memeriksa perubahan seperti kembali ke dalam kendali sumber.

— FrustratedWithFormsDesigner

18

Pertama-tama, dalam contoh Anda ada komentar "TODO". Jenis komentar ini istimewa karena terdeteksi oleh IDE (setidaknya Eclipse dan Visual Studio) sebagai penanda untuk "tugas". Tapi saya yakin Anda tahu itu karena Anda menggunakan ini, dan saya kira Anda tidak merujuk mereka ketika Anda menggunakan istilah "kode dinonaktifkan".

Adapun kode yang dinonaktifkan itu sendiri, pendapat saya adalah bahwa itu mencemari kode. Saya menggunakan mekanisme lain untuk melacak apa yang ada sebelumnya: repositori sumber . Kecuali ketika saya berada dalam mode kode / tes / kode / tes ..., saya tidak mengomentari kode yang tidak digunakan, saya menghapusnya. Dan ketika itu terjadi, mengomentari garis X hanya masalah satu pintasan keyboard.

Sunting: jadi ya, saya lupa menjawab pertanyaan eksplisit Anda, saya pikir tidak ada gunanya memiliki komentar khusus untuk kode yang dinonaktifkan. Jika Anda benar-benar ingin menyimpan kode, tetapi katakan "jangan gunakan itu", Anda selalu dapat menandainya sebagai @deprecated tetapi itu bukan poin dari pertanyaan Anda.

— Jalayn
sumber

Saya dulu menulis kode kotor dan bangga menggunakan "peretasan" dan perbaikan cepat, saat ini saya menghargai struktur - mungkin saya bisa terbiasa dengan ini juga.

— deltreme

2

TLDR; Gunakan kontrol sumber.

— Chris

1

@trtreme Saya mengakui bahwa saya melakukan hal yang sama (tunjukkan bagaimana saya "meningkatkan" kode!) sebelum saya mulai menggunakan repositori sumber dalam lingkungan profesional. Sejak itu, saya menghargai harus membaca baris kode paling sedikit yang harus saya lakukan setiap hari.

— Jalayn

Gunakan kontrol sumber dan teliti diff sebelum melakukan.

— UncleZeiv

1

Sayangnya, fokus balasan adalah pada bagaimana tidak melakukan kode yang dinonaktifkan, bukan pada seberapa konyol istilah "berkomentar" sebenarnya. Saya mengharapkan lebih banyak campuran. Menerima jawaban ini ketika saya meminta pendapat dan komunitas Anda mendukung Anda: P

— deltreme

5

Untuk beberapa alasan selama pengembangan, saya terkadang berkomentar keluar kode. Karena saya kacau dan kadang-kadang terburu-buru, beberapa di antaranya membuatnya menjadi kontrol sumber.

Saya pikir ini adalah akar masalahnya. Menjadi kacau dan terburu-buru hanya akan menimbulkan masalah. Mencari tahu mengapa pengembangan Anda sedang terburu-buru dan tidak terkontrol dengan baik harus menjadi langkah pertama, bukan mencoba mencari kode komentar.

Jadi, ketika kode komentar terjadi dalam setiap (?) Bahasa, bukankah seharusnya "kode yang dinonaktifkan" mendapatkan sintaksnya sendiri dalam spesifikasi bahasa? Apakah pro (pemisahan komentar / kode yang dinonaktifkan, editor / kontrol sumber bertindak atas mereka) cukup baik dan kontra ("toh tidak boleh berkomentar-keluar", bukan bagian fungsional dari bahasa) layak dikorbankan?

Saya kira tidak. Mengomentari kode adalah praktik yang buruk dan saya tidak berpikir bahasa harus mendorong siapa pun untuk menggunakannya. Ya, orang-orang melakukannya dan saya sudah melihatnya, tetapi saya menolak untuk memeriksa kode saya yang dikomentari. Memberi orang kemampuan untuk dengan mudah mengelola kode lama yang tidak digunakan, berada di luar cakupan bahasa dan merupakan sesuatu yang termasuk dalam ranah kontrol versi.

Saya juga khawatir tentang keterbatasan teknis. Agar ini berfungsi, Anda perlu mengurai komentar dan menentukan apakah komentar tersebut dikomentari sumber atau teks atau menambahkan token baru ke bahasa. Bergantung pada kompleksitas bahasa saat ini, saya tidak sepenuhnya yakin apa dampak ini pada kompilasi (mengidentifikasi apakah suatu baris adalah kode yang valid atau tidak untuk dikompilasi). Selain itu, orang kemudian akan mengharapkan IDE untuk mengelola ini secara real time (apakah ada hubungan antara kompleksitas sintaksis bahasa dan responsif IDE untuk menemukan dan menyoroti berbagai konstruksi dan kesalahan).

— Thomas Owens
sumber

Saya mencoba untuk mengatur kekacauan dan terburu-buru saya, dan saya setuju sepenuhnya di situlah semuanya dimulai. Namun saat ini terjadi dan saya yakin bahwa segera setelah saya bebas dari kode komentar, orang lain akan menggantikan saya. Mungkin aku hanya mengomel. Pada akhirnya itu bukan masalah besar. Adapun aspek teknis: IDE bahkan dapat memperlakukan mereka sebagai komentar biasa, menggunakan warna, atau menyembunyikannya - banyak IDE sudah mendukung ini untuk elemen sintaksis lainnya.

— deltreme

@trtreme Saya tidak peduli bagaimana IDE akan mendukung mereka di permukaan. Bagaimana cara IDE menemukan dan memprosesnya dengan cara yang akurat namun mempertahankan daya tanggap? Menambahkan token ke bahasa atau menambahkan pemrosesan teks memiliki potensi untuk memperlambat penguraian atau menghasilkan hasil yang tidak akurat.

— Thomas Owens

Saya tidak berpikir diskusi akan seperti ini :) Dan saya tidak berpikir menambahkan token lain (berapa banyak yang dikenali oleh IDE modern saat ini?) Akan menghasilkan editor yang kurang responsif. Jika Anda melihatnya sebagai ancaman potensial bahkan dalam tahap penelitian "proyek" ini, akankah Anda memiliki perkiraan berapa% kehilangan kinerja? Katakanlah kita menambahkan token dan ingin warna untuk itu dalam IDE.

— deltreme

@dtrtreme Saya tidak berpikir itu akan menambah banyak waktu untuk sebagian besar proyek, tetapi dalam hal waktu ditambahkan / nilai tambah, rasionya sangat buruk. Jika Anda harus menambahkan beberapa mikrodetik tambahan ke puluhan ribu file sumber, Anda hanya menambahkan milidetik ke segala sesuatu yang pernah mem-parsing file sumber, setiap kali Anda mengurai file sumber. Untuk sebuah IDE, biasanya setiap kali Anda menghemat. Itu juga untuk post-commit dan / atau build harian Anda. Buat milidetik tersebut dan dengan cepat menjadi terukur dalam hitungan menit selama masa proyek untuk menangani fitur yang tidak menambah nilai.

— Thomas Owens

1

@trtreme Sama sekali tidak. Jika Anda telah menonaktifkan kode di proyek Anda yang membuatnya menjadi kontrol sumber, Anda salah melakukannya. Kadang-kadang, jika saya menulis ulang suatu metode, saya mungkin berkomentar tentang metode yang lama dan menerapkannya kembali, tetapi begitu saya yakin kode baru itu lulus tes dan berfungsi sebagaimana dimaksud, saya menghapus kode yang dinonaktifkan dan memeriksanya. Jika Anda sebenarnya memeriksa dalam kode yang dinonaktifkan atau mengandalkannya dalam beberapa cara, itu pertanda masalah yang lebih besar dalam proyek yang perlu ditangani.

— Thomas Owens

4

Bahkan jika hanya ada satu sintaks komentar dalam bahasa yang Anda gunakan, Anda masih dapat menambahkan rasa Anda sendiri ke dalamnya, saya telah mengerjakan proyek-proyek di mana // menunjukkan garis yang dinonaktifkan dan // - menunjukkan komentar. Ini tidak sebagus dibangun di dalamnya, tetapi sebagian besar IDE tidak tahu Anda telah menggunakan sintaks yang berbeda untuk tujuan yang berbeda, jadi kadang-kadang cara lama eyeballing untuk melihat perbedaannya paling baik.

— Nicholas Smith
sumber

Jika tim mendedikasikan rasa ini, itu akan menjadi solusi yang baik. Bahkan "on-commit-hook" -able, dan jika Anda lupa karakter tambahan untuk sesuatu yang dimaksudkan sebagai komentar, itu juga akan mengingatkan.

— deltreme

1

Bertentangan dengan jawaban, saya akan menjawab dengan "YA, harus ada sintaks yang berbeda!"

Saya akan menantang pengembang mana pun untuk mengatakan bahwa mereka menjalani satu hari pengkodean tanpa mengomentari kode. Untuk melakukannya bukan berarti orang tidak tahu kontrol sumber atau malas. Bahkan seperti yang dikatakan Thomas Owens dalam jawaban yang berbeda, " Kecuali ketika saya berada dalam mode kode / tes / kode / tes ..., saya tidak berkomentar kode yang tidak digunakan. "

Berapa banyak waktu Anda dihabiskan dalam mode kode / tes / kode / tes? Bagi saya itu setidaknya 90% pekerjaan! Saat ini saya sedang mengonversi proyek OSX besar ke iOS, dan langkah pertama adalah menonaktifkan semua kode yang melanggar sampai saya memiliki sebuah rintisan yang berfungsi. Untuk minggu-minggu berikutnya saya akan perlahan-lahan menghapus komentar dan memperbaiki kode ketika saya membuatnya berfungsi.

Ada banyak kasus lain juga. Bagaimana dengan ketika Anda menggunakan kode contoh tempat Anda sering menemukan arahan seperti "Batalkan komentar berikut untuk Windows" atau "Batalkan komentar pada baris ini untuk Aplikasi khusus iPhone"?

Ya, saya akan menggunakan kontrol sumber selama ini. Tetapi juga YA, saya ingin ada cara untuk membedakan kode yang dinonaktifkan dari komentar yang sebenarnya.

Singkatnya: Setiap programmer yang mengatakan mereka tidak menggunakan komentar untuk menonaktifkan kode adalah bohong. Ada lebih banyak pengkodean daripada file dipoles yang Anda komit ke HEAD. Ada banyak alasan valid untuk kode yang dinonaktifkan.

Ya akan lebih baik jika ada sintaks (atau setidaknya konvensi) untuk membedakan komentar yang benar dari kode yang dinonaktifkan.

— Stan James
sumber