Kode mewah pendek yang dikomentari vs. kode mudah dimengerti yang tidak diomongkan lebih lama - mana yang lebih disukai?

Terkadang suatu algoritma dapat ditulis dalam dua cara:

• Cara pendek dan mewah; atau
• Cara yang lebih panjang dan mudah dipahami.

Misalnya, ini cara yang lebih panjang dan lebih mudah untuk menyalin string sourceke destdalam C:

*dest = *source;
while (*source != '\0') {
    source++;
    dest++;
    *dest = *source;
} (true);

Dan ini cara yang pendek dan mewah.

// Copy string source to dest
while (*dest++ = *source++);

Saya selalu mendengar dan membaca bahwa kode mewah harus dihindari, dan saya cenderung setuju. Tetapi bagaimana jika kita mempertimbangkannya? Anggaplah, seperti dalam contoh di atas, kita memiliki kode yang tidak diomentari, lebih panjang dan lebih mudah dipahami, dan kode mewah yang dikomentari dengan baik? Apakah kode yang tidak mewah masih disukai?

EDIT: Banyak yang mengomentari nama variabel, jadi saya telah memodifikasi kode contoh agar tidak menjadikannya faktor ketika lebih memilih yang lain. Saya mencoba untuk menghapus penugasan ganda pada contoh pertama, tetapi itu hanya membuat kode kurang dibaca.

Mungkin ini bukan contoh terbaik karena banyak yang menemukan kode 'mewah' lebih mudah dibaca dan dimengerti daripada kode yang lebih panjang. Idenya adalah memiliki satu kode yang lebih panjang yang jauh lebih mudah dipahami daripada kode yang sangat pendek namun rumit.

EDIT2: Ini contoh baru yang saya dapat dari SO :

Versi mewah berkomentar:

//direct formula for xoring all numbers from 1 to N
int Sum = (N & (N % 2 ? 0 : ~0) | ( ((N & 2)>>1) ^ (N & 1) ) );

Versi panjang tanpa komentar:

int Sum = 0;
for (int i = 1; i < N; ++i)
{
   Sum ^= i; //or Sum = Sum ^ i;
}

Saya biasanya lebih suka mengekstrak kode mewah ke metode sendiri ..

Alih-alih mengomentari kode mewah, nama metode haruslah yang dibutuhkan untuk memperjelas.

char *copy_string(char *s, const char *t) {    
    while (*s++ = *t++); 
    return s;
}

Saya semua untuk versi yang lebih panjang. Masalah dengan versi pendek kode, selain lebih sulit dibaca oleh beberapa programmer, adalah bahwa sebagian besar waktu lebih sulit untuk menemukan kesalahan hanya dengan melihatnya.

Saya punya contoh kehidupan nyata. Dalam produk kami, kami memiliki cuplikan kode berikut:

if (++someCounter < MAX_VALUE) {
    // Do something that has to be done only MAX_VALUE times
}

Kode ini terlihat sangat masuk akal pada pandangan pertama, tetapi setelah jangka waktu yang lama, penghitung ini meluap dan merusak kondisi (dalam skenario kehidupan nyata kami menghancurkan sistem produksi klien kami dengan OOM). Kode ini sedikit kurang "canggih", tetapi jelas bahwa ia melakukan apa yang seharusnya dilakukan:

if (someCounter < MAX_VALUE) {
    ++someCounter;
    // Do whatever it is we came here for
}

Dan Anda dapat mengatakan bahwa pengembang yang menulis kode ini tidak cukup baik (yang tidak benar, ia adalah orang yang cukup cerdas), tetapi saya berpikir bahwa jika teknik pengkodean Anda mengharuskan Anda menjadi super-duper, ahli pemrograman, D Untuk mendapatkan kode Anda yang benar, Anda melakukan sesuatu yang salah. Kode Anda harus sesederhana mungkin demi Anda dan bagi siapa pun yang harus mempertahankan kode ini setelah Anda (yang mungkin tidak sepintar Anda).

Jadi - saya semua untuk kesederhanaan dan kejelasan.

Sunting: Oh, dan mengenai komentar - tidak masalah. Banyak orang yang tidak akan membaca komentar ( http://www.javaspecialists.co.za/archive/Issue039.html ) dan mereka yang tidak akan memahami kode Anda tanpa komentar, tidak akan memahaminya dengan cukup baik sehingga mereka tidak dapat mempertahankannya. Tujuannya adalah untuk membantu orang melihat bahwa kode tertentu "benar", komentar tidak dapat membantu dengan itu.

Saya biasanya lebih suka versi yang lebih panjang. Dua alasan utama muncul dalam pikiran:

• Semakin banyak orang cenderung memahaminya dengan sedikit usaha (dengan asumsi itu bukan contoh "standar" seperti salinan string ini).
• Dimungkinkan untuk menempatkan breakpoint pada pernyataan individual dan melangkah maju dengan debugger.

Untuk yang terbaik dari kedua dunia, bungkus kode dalam suatu fungsi, yang namanya mengomentari untuk Anda:

void copy_string(char *s, char *t)
{
    *s = *t;
    while (*t != '\0') {
        t++;
        s++;
        *s = *t;
    }
}

Satu-satunya alasan untuk tidak melakukan ini adalah jika kinerja merupakan masalah dan pembuatan profil benar-benar menunjukkan fungsi overhead menjadi signifikan.

Apa pun yang paling jelas. Seringkali itu adalah cuplikan kode yang mudah dimengerti dan tidak memerlukan komentar ... seperti contoh kedua Anda.

Cuplikan kode yang lebih pendek umumnya lebih mudah dipahami karena jumlah pembaca kurang untuk diingat. Jelas, ada batasan ketika kode terlalu dikaburkan dan saya tidak bermaksud bahwa kejelasan meningkatkan ruang putih harus dipangkas.

Komentar tidak boleh menyatakan apa pun yang jelas dari kode, yang hanya membuat pembaca membaca hal yang sama dua kali. Bagi saya cuplikan pertama memerlukan klarifikasi. Mengapa pengembang belum menggunakan do...whileloop untuk menghapus duplikat *s = *t;tugas? Saya harus mengurai lebih banyak kode untuk menyadari bahwa itu menerapkan salinan string. Suatu komentar akan lebih membantu pada kode yang lebih panjang ini daripada pada kode yang lebih pendek.

Komentar pada snippet kedua hampir redundan seperti itu sementara loop praktis idiomatis, tetapi ia mengatakan apa yang dilakukan kode pada level yang lebih tinggi daripada kode itu sendiri yang membuatnya menjadi komentar yang berguna.

Masalahnya adalah bahwa tidak ada definisi yang jelas short fancy codekarena sangat tergantung pada level programmer. Sementara beberapa orang tidak memiliki masalah dalam memahami suatu while(*s++ = *t++);ekspresi, yang lain akan.

Secara pribadi saya menemukan yang while(*s++ = *t++);terbaca sempurna dan yang lebih lama lebih sulit dibaca. Orang lain mungkin tidak setuju.

Apapun, itu hanya masalah menggunakan akal sehat. Keterbacaan harus jelas menjadi prioritas, tetapi ada titik di mana kode yang lebih panjang menjadi kurang terbaca ketika semakin lama. Verbositas sering mengurangi keterbacaan dari pengalaman saya.

Saya harus tidak setuju dengan sebagian besar jawaban lain di sini - saya pikir (setidaknya dalam hal ini) kode yang lebih pendek lebih baik. Bertentangan dengan klaim Anda, kode yang lebih panjang tidak "lebih mudah", setidaknya untuk pembaca. Jika ada, Anda tampaknya telah keluar dari keinginan Anda untuk membuatnya lebih lama, meskipun itu membuat kode lebih sulit untuk dipahami dan / atau dijamin operasi yang benar.

Secara khusus, memiliki tugas byte pertama dari string luar loop, terpisah dari tugas untuk byte lain, berarti orang harus jauh lebih berhati-hati dalam membaca untuk memastikan bahwa semua byte disalin dengan benar. Urutan dasar tindakan dalam versi yang lebih pendek jauh lebih mudah untuk diverifikasi. Satu-satunya masalah sebenarnya adalah dalam pemformatan - saat Anda memiliki badan loop kosong yang disengaja, yang terbaik adalah membuatnya menjadi jelas, sesuatu seperti:

while (*dest++ = *source++)
    ;

atau bahkan:

while (*dest++ = *source++)
    ; /* no body */

Beberapa orang lebih suka menggunakan kawat gigi sebagai gantinya:

while (*dest++ = *source++)
    {}

Terlepas dari pemformatan yang Anda inginkan, cukup banyak kesalahan yang dilakukan dengan hal-hal seperti:

if (x>y);
     x = z;

... bahwa penting untuk memastikan bahwa 1) sudah jelas apa yang sebenarnya dikontrol oleh aliran-kontrol, dan 2) sudah jelas bahwa kode itu ditulis mengetahui apa yang dikontrol olehnya, jadi seseorang yang membacanya tidak membuang waktu untuk mencoba untuk mengetahui apakah mereka baru saja menemukan bug.

Keep it simple, stupid!

Pastikan programmer lain dapat memahami apa yang kode Anda lakukan — dan bahkan lebih baik jika dilihat sekilas (di sinilah nama dan komentar yang baik muncul dengan sendirinya).

Kay-fu bit-twiddling dan perakitan inline bagus untuk optimasi (mungkin tidak perlu dan prematur), tetapi ketika Anda bahkan tidak dapat memahami kode yang Anda tulis ketika menemukan bug di dalamnya dua bulan kemudian .. Apa gunanya? Anda akan menghabiskan waktu dan usaha sendiri.

Saya sering merujuk ke Zen Python dalam situasi ini. Khususnya:

Explicit is better than implicit.
Simple is better than complex.

Jangan menulis kode mewah dalam perangkat lunak produksi. Saya tahu rasanya senang bisa benar-benar menulis itu, dan lebih pendek. Menulis kode mewah secara signifikan meningkatkan nilai "WTF / menit", dengan kata lain menurunkan kualitas.

Itu tentu saja sepenuhnya tergantung pada keadaan. tetapi secara umum, saya menemukan ini sebagai aturan praktis yang baik:

Debugging dua kali lebih sulit daripada menulis kode di tempat pertama. Oleh karena itu, jika Anda menulis kode sepintar mungkin, Anda, menurut definisi, tidak cukup pintar untuk debug itu.

~ Brian Kernighan

Dalam pengalaman saya, kemenangan terbesar dalam hal kode mewah pendek cenderung menggunakan rekursi daripada iterasi. Ini juga salah satu hal yang paling sulit untuk dipahami dalam sekilas kode, kecuali jika Anda bekerja dalam jenis bahasa di mana semuanya bersifat rekursif. Saya masih menginginkannya untuk keanggunan dan kecepatan pengembangan yang ditawarkannya, tetapi saya mencoba memastikan bahwa komentarnya terperinci jika kelihatannya akan buram bagi para pengelola di masa depan atau diri saya di masa depan.

Saya mulai tidak percaya pada komentar. Terlalu sering, komentar tidak diperbarui ketika kode diperbarui dan jauh dari ketinggalan zaman atau mewakili aturan dari klien / manajemen yang tidak lagi relevan.

Sudah sampai pada titik dalam beberapa kasus di mana komentar bahkan tidak cocok dengan kode yang mereka gambarkan lagi.

Jika saya harus memilih antara pendek / mewah dan lebih lama / lebih mudah dimengerti maka saya selalu memilih yang terakhir kecuali ada alasan yang sangat bagus.

Keterbacaan dan pemeliharaan adalah kunci, dan contoh kedua Anda (yaitu yang lebih lama) jauh lebih baik dari keduanya. Tetapi mengapa membatasi diri Anda pada dua pilihan? Bahkan kode yang lebih panjang terlalu kompleks (IMHO) untuk tidak memberi tahu lebih lanjut. Saya akan memasukkannya ke dalam metode sendiri dengan Javadoc yang sesuai (atau apa pun) dan nama metode yang sesuai.