"// ..." komentar di akhir blok kode setelah}

18

Ditutup . Pertanyaan ini didasarkan pada pendapat . Saat ini tidak menerima jawaban.

Ingin meningkatkan pertanyaan ini? Perbarui pertanyaan sehingga dapat dijawab dengan fakta dan kutipan dengan mengedit posting ini .

Ditutup 4 tahun yang lalu .

Saya sering melihat komentar seperti itu digunakan:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

dan terkadang bahkan sejauh

if (condition) {
   ...
} // if (condition)

Saya tidak pernah mengerti praktik ini dan karenanya tidak pernah menerapkannya. Jika kode Anda terlalu panjang sehingga Anda perlu tahu akhir cerita }ini, mungkin Anda harus mempertimbangkan untuk memecahnya menjadi beberapa fungsi yang terpisah. Juga, sebagian besar alat pengembang dapat melompat ke braket yang cocok. Dan akhirnya, bagi saya, merupakan pelanggaran yang jelas terhadap prinsip KERING; jika Anda mengubah kondisi, Anda harus ingat untuk mengubah komentar juga (atau yang lain bisa berantakan untuk pengelola, atau bahkan untuk Anda).

Jadi mengapa orang menggunakan ini? Haruskah kita menggunakannya, atau itu praktik yang buruk?

source-code comments

— Gablin
sumber

Dalam PHP, saya menggunakan sintaks alternatif untuk struktur kontrolif(condition): ... else: ... endif;

— systemovich

@ Geoffrey van Wyk - benarkah? Saya belum pernah melihat orang menggunakan ini di luar file template. Mereka sangat tidak standar, tetapi untuk masing-masing mereka sendiri, saya kira.

— Craige

4

@Craige: Konstruk bahasa apa pun yang didukung oleh PHP bukan "Extremely Unstandard" - penerjemah PHP mendefinisikan apa itu "standar".

— Billy ONeal

Ada memiliki penanda khusus untuk akhir yang paling konstruksi: if ... then ... end if; while ... loop ... end loop; procedure Foo is ... end Foo;. Saya menemukan bahwa ini membantu keterbacaan (dan diperiksa oleh kompiler, yang komentarnya tidak).

— Keith Thompson

32

Saya akan mengatakan jika kode Anda terlalu panjang sehingga Anda tidak dapat dengan mudah mengikuti kawat gigi Anda, kode Anda perlu refactoring, untuk sebagian besar bahasa.

Namun, dalam bahasa templating (seperti PHP) itu bisa valid, karena Anda mungkin memiliki blok besar HTML yang memisahkan awal dan akhir dari kondisi atau struktur loop.

— Matt Ellen
sumber

5

Poin yang benar-benar valid untuk PHP, jika Anda menggunakan PHP dicampur dengan Html. 1 poin untuk Gryffindor.

3

Bahkan dengan PHP sebagai bahasa templating yang dicampur dengan HTML, Anda masih bisa membuat indentasi. Anda juga tidak harus menggunakan kawat gigi ketika menggunakan PHP sebagai bahasa templating, tetapi lebih pada while(): endwhile;dan foreach(): endforeach;membangun dll.

— Htbaa

9

Saya tidak benar-benar mengerti mengapa Anda tidak boleh melakukan refactoring pada PHP. Mungkin ke bahasa lain.

— Tom Hawtin - tackline

@ Htbaa: Saya tidak percaya saya telah menggunakan PHP selama ini dan tidak tahu tentang itu. Terima kasih! Mengenai indentasi, saya lebih memilih untuk tetap membuat indentasi HTML sama dengan bagian halaman lainnya, daripada sejalan dengan PHP yang membuatnya.

— Matt Ellen

3

@ Tom: Saya tertawa, tetapi merasa bersalah. : P

17

Ini bau kode dan biasanya mabuk dari gaya kode kuno. Sebelum refactoring IDE yang layak lebih sulit dan tidak biasa seperti sekarang, maka metode lebih lama dan komentar ini ada untuk membantu menavigasi mereka dengan lebih baik.

— Alb
sumber

15

Ini adalah praktik mengerikan yang dibuat usang oleh banyak faktor.

Sebagian besar IDE modern menyoroti penjepit yang sesuai ketika tanda sisipan berada pada kedua simbol.
Jika Anda mengkode dengan bersih, Anda jarang akan menemukan tempat di mana metode Anda lebih dari 10 baris.

Saya melihat banyak programmer Java memiliki pola pikir ini, dan itu membuat kode Java terlihat sangat kotor dan mengalihkan fokus dari kode dan menuju komentar.

Sangat tidak menyarankan untuk menggunakan ini.

4

Saya memiliki rekan kerja (pengembang java) yang melakukan ini. Kecuali alih-alih // untuk dan // jika dia menggunakan // rof dan // fi. Itu membuatku gila dan dia melakukannya di mana-mana.

— Jay

Ya saya punya satu yang bersikeras. AAAAAGHHHHH.

— Rig

2

Ini benar-benar tidak ada hubungannya dengan Java atau programmer Java, dan itu tidak umum atau standar de-facto untuk dilakukan ketika pemrograman di Java.

— Jesper

1

+1,000 untuk "adalah praktik yang mengerikan".

— scunliffe

6

Kode dibaca 10 kali lebih banyak daripada yang tertulis.

Jika itu membuatnya lebih mudah dibaca, lakukanlah.

Saya juga menyarankan kepada siapa pun yang melakukan ini agar mereka melihat beberapa cara lain agar lebih mudah dibaca. Teknik refactoring, tanda kurung pada jalur yang berbeda, dll. Yang telah disebutkan orang lain semuanya baik. Membagi hal-hal menjadi fungsi, metode atau kelas yang berbeda sehingga kode berkomentar sendiri juga bagus. Ada juga cara untuk menghilangkan sebagian besar "seandainya" dan menempatkan "untuk" loop ke tempat yang jelas, sehingga menghilangkan kebutuhan untuk semua ini.

Tapi, terkadang orang belajar. Jika ini adalah sesuatu yang mereka lakukan yang benar-benar membuat kode lebih mudah dibaca, dorong, dan dorong beberapa praktik lain juga. Orang yang belajar layak dan akan mendapat manfaat dari dorongan, terlepas dari bagaimana mereka memulai. Mengatakan "Ini buruk" tidak berguna seperti mengatakan "Hal lain ini lebih baik".

— Lunivore
sumber

6

Ini adalah buruk. Bahkan buku teks tingkat pemula tidak melakukan kekejaman ini. "Kode dibaca 10 kali lebih banyak daripada yang tertulis" ... lebih banyak alasan untuk tidak menyia-nyiakan waktu pembaca dengan kode ini.

— Thomas Eding

@trinithis Bagaimana jika Anda memiliki statement switch 20-case? Kadang-kadang Anda perlu mendukung 20 opsi yang berbeda, dan lebih baik mengumpulkannya di satu tempat daripada "refactored" ke dalam beberapa skema pengambilan keputusan multi-level.

— quant_dev

Saya percaya ini adalah praktik oleh coders yang meremehkan teman sebaya :) bahwa orang lain tidak cukup pintar untuk membaca kode kecuali. Secara umum saya menentang praktik ini, tetapi oke jika seseorang melakukannya karena ada hutan yang membuatnya sulit dibaca. saya tidak melakukan itu!

— WinW

1

@trinithis Ini bukan tentang apakah itu buruk atau tidak, ini tentang cara yang efektif untuk membantu orang menjadi lebih baik sehingga mereka tumbuh melewatinya. Menjadi efektif> menjadi benar. Ini juga merupakan hal yang masuk akal untuk dilakukan jika, katakanlah, Anda sedang me-refactoring kode warisan yang bahkan lebih berantakan. Terkadang hal-hal buruk dapat membuat langkah sementara yang lebih baik dan menghasilkan sesuatu yang lebih baik dari itu.

— Lunivore

1

@trinithis Maaf, saya tidak tahu apa yang Anda maksud ketika semuanya dalam satu baris seperti itu. Saya pikir saya sebutkan bahwa ada juga cara lain untuk refactoring kode yang bisa dipelajari oleh para pengembang ini.

— Lunivore

4

Saya punya basis kode besar (C ++) yang penuh dengan hal semacam ini:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

Untuk hal sekecil ini, saya akan mengatakan ini melampaui "bau kode" menjadi "kode bau". Terutama dalam IDE di mana saya dapat mencocokkan penjepit penutup dengan keystroke untuk menemukan penjepit pembuka. Dengan metode yang lebih panjang, saya akan tetap menggunakan brace yang cocok dengan komentar terminal. Komentar seperti itu mengalihkan perhatian saya, dan saya cenderung menganggapnya sebagai kebisingan.

— PSU
sumber

Um, saya kira saya tidak mendapatkan beberapa format di situs ini; masing-masing penjepit di sana harus pada jalurnya sendiri, seperti halnya tubuh metode.

— PSU

Dalam C ++ saya akan sering membuka namespace anonim di bagian atas untuk hal-hal implementasi tersembunyi. Kemudian pada titik tertentu saya menutup brace ini dan berguna untuk mengetahui apa arti close-brace di sini.

— CashCow

4

Di C ++ ada dua peninggalan di mana ini masih berguna dan saran "pisahkan kode Anda" tidak perlu ditahan:

Untuk ruang nama. Namespace dapat mencakup seluruh file, dan braket terakhir itu kadang-kadang dapat membuat orang menjauh, jadi menambahkan komentar untuk menunjukkan braket adalah penutupan namespace berguna. Untuk gaya pengkodean khusus di perusahaan saya ini penting karena kami tidak membuat indentasi ruang nama karena diputuskan bahwa lekukan seperti itu hanya akan membuang-buang ruang dalam file.
Untuk pasangan #ifdef / #endif. Kadang-kadang ada banyak kode di sana untuk kompilasi bersyarat, itu bisa menjadi buruk dengan bersarang, dan editor yang kita gunakan sering kali "membantu" menghilangkan lekukan, sehingga komentar berguna selama tinjauan singkat.

— Joris Timmermans
sumber

+1 untuk komentar namespace dan alasannya. Itulah satu-satunya waktu saya melakukan ini dan untuk alasan yang sama

— JohnB

+ pernyataan sakelar panjang.

— quant_dev

1

Bagi saya kode harus membingungkan untuk menambahkan komentar seperti yang Anda tentukan.

Jika hanya mengatakan // JIKA Pernyataan. Maka Anda harus bertanya-tanya mengapa itu ada di sana.

— TehMinumGeek
sumber

Saya setuju, sepertinya kalimat yang dikomentari, bukan sekolah tua//endif

— StuperUser

1

Alternatif untuk melihat apa yang ditutup oleh brace Anda adalah membuka yang pada kolom yang sama dengan yang dekat. Saya menemukan itu jauh lebih jelas dan lebih mudah dibaca.

Komentar ini berguna ketika biasanya sulit dilacak karena pembukaan terjadi sejak lama. Ini biasanya terjadi hanya untuk namespace (terutama yang anonim di C ++, digunakan untuk detail implementasi di unit kompilasi). Dalam kebanyakan kasus lain, harus jelas apa yang Anda tutup.

— Uang tunai
sumber

1

Ini sebagian besar merupakan peninggalan dari masa lalu bekerja di windows 80x24 karakter terminal, terutama jika Anda menggunakan editor berjendela seperti EVE. Bahkan sekarang, saya melakukan sebagian besar pekerjaan saya dalam sesi terminal menggunakan vim, dan saya dapat membagi sesi menjadi tiga atau empat subwindows, jadi saya hanya dapat benar-benar melihat beberapa baris sekaligus.

Yang mengatakan, saya tidak pernah benar-benar hangat ke kebaktian, meskipun itu akan menghemat bacon saya lebih dari satu kali. Saya hanya melihatnya sebagai kebisingan. Jika loop atau kondisi Anda menjadi sebesar itu, ya, Anda mungkin ingin melihat ke dalam refactoring.

— John Bode
sumber

0

Anda pada dasarnya memberikan semua alasan yang valid mengapa tidak menggunakan ini. Setiap programmer yang layak harus menerapkan ini. Jadi, mengapa tidak orang menggunakannya? Karena mereka melakukan kesalahan dan tidak tahu yang lebih baik.

— stijn
sumber

erm, tolong jelaskan downvote. Saya tidak hanya menciptakan jawaban ini, itu berasal dari pengalaman kehidupan nyata: kolega saya yang duduk beberapa kaki di sebelah saya telah memprogram lebih dari 10 telinga seperti itu dan tidak tahu mengapa ini salah sampai saya menjelaskan kepadanya .

— stijn

Mungkin itu digunakan dalam beberapa buku pelajaran sehingga sekelompok orang keluar dari perguruan tinggi menggunakannya? Itu bisa memiliki tempat dalam teks pengantar. Juga cukup masuk akal dalam preprocessor, terutama di # ifdef / endif termasuk penjaga

— Martin Beckett

"// ..." komentar di akhir blok kode setelah} - baik atau buruk? [Tutup]