Ya, benar? Apakah itu dianggap praktik yang buruk?

IMO, kurang dibaca. Aku benci harus menggulir ke kanan, lalu kembali ke kiri, ke kanan, ke kiri, dan seterusnya. Itu membuat pengkodean lebih menyakitkan dan terkadang membingungkan saya.

Sebagai contoh, kapan saja saya mengkodekan string panjang, saya akan melakukan hal berikut ...

bigLongSqlStatement = "select * from sometable st inner join anothertable at" +
"on st.id = at.id" +
"and so on..." +
"and so on..." +
"and so on..."

Ya, memang demikian, dalam arti literal dan juga pengertian umum.

Saya suka melakukan diffs kode berdampingan, dan garis yang terlalu lebar membuat itu lebih sulit:

Bahasa seperti Scala dengan string yang dikutip tiga kali lipat memungkinkan Anda membuat string dari banyak baris tanpa biaya runtime, kutipan yang tidak sedap dipandang dan tanda plus (seperti terlihat dalam contoh Anda) untuk menggabungkan bagian-bagian string.

Ya, saya pikir 80 karakter per baris masuk akal dan umum digunakan.

Ini adalah pertanyaan yang sangat penting bagi saya! Saya telah bekerja 7 bulan pada laptop 13 "dengan rekan kerja yang memiliki monitor desktop 24", dan saya mendapati diri saya menghabiskan banyak waktu memperpendek garis untuk menghasilkan sesuatu yang dapat dibaca.

80 kolom agak kecil dalam banyak kasus (kecuali jika Anda bekerja pada terminal dengan vi satu-satunya pilihan;)), tetapi lebih dari ~ 150 terlalu banyak (lihat di bawah).

Itu untuk pertanyaan 'keterbacaan' murni.

Sekarang, untuk bagian 'praktik yang baik', saya sangat sering menemukan garis panjang seperti itu cacat, yaitu memiliki beberapa bagian yang harus diekstraksi dalam variabel sementara, atau yang digandakan, misalnya (ObjectiveC, cuplikan umum dalam pemrograman iPhone) :

CGPoint point = CGPointMake(someOtherView.frame.origin.x + someOtherView.frame.size.width, someOtherView.frame.origin.x + someOtherView.frame.size.height);

Harap dicatat ini dapat menjadi lebih nastier saat bekerja dengan vektor atau matriks 3 dimensi.

Contoh yang ditulis ulang:

CGRect frame = someOtherView.frame;
CGPoint origin = frame.origin;
CGSize size = frame.size;
CGPoint point = CGPointMake(origin.x + size.width, origin.x + size.height);

Ini sekarang pas pada layar yang lebih kecil, lebih mudah untuk debug menggunakan IDE atau menulis ke output standar, dan bahkan mungkin lebih cepat, tergantung pada biaya metode / properti permintaan. Ini agak dipaksakan tentu saja, sebagian besar contoh dunia nyata jauh lebih kompleks ...

Tidak selalu.

Hanya untuk menambahkan tampilan alternatif, ketika saya membaca kode saya sering bisa mendapatkan inti dari apa yang dilakukan oleh baris kode tanpa harus membaca seluruh baris. Jika saya bisa membaca nama metode tetapi parameter metode keluar dari layar, saya biasanya tidak repot karena saya tahu dari nama metode saja apa maksud dari baris kode itu. Jika beberapa baris kode keluar dari layar maka saya pikir trade off karena harus sesekali (kata penting di sana) gulir secara horizontal sepadan dengan kode yang lebih ringkas. Saya kadang-kadang menemukan multi-line kode pernyataan tunggal mengganggu karena saya harus secara mental mengumpulkan kode mana yang sesuai dengan pernyataan yang mana.

Seringkali, baris kode yang tumpah secara horizontal memiliki bit penting di sebelah kiri (terlihat) dan bit kurang penting di sebelah kanan (di luar layar), jadi bagi saya ini meningkatkan keterbacaan karena saya dapat memindai kode ke bawah sebagian besar melihat bit-bit penting pada setiap baris sebagai lawan dari alternatif memiliki bit-bit kode yang kurang penting dari garis yang terlalu panjang yang mengambil ruang sisi kiri yang secara visual penting pada baris-baris berikut.

Setelah mengatakan semua itu, saya tentu tidak ingin terlalu sering menggulir secara horizontal, tetapi saya menemukan ini kurang menjadi masalah di hari-hari monitor layar lebar ini.

Ya, benar.

Kebetulan tip. Jika Anda menggunakan bahasa dengan string multi-line (hampir semua bahasa scripting memilikinya) dan termasuk SQL panjang, itu benar-benar membantu keterbacaan untuk menempatkan SQL dalam string multi-line menggunakan aturan format yang konsisten untuk SQL. Lihat http://bentilly.blogspot.com/2011/02/sql-formatting-style.html untuk gaya format yang saya gunakan.

Tidak, tidak.

Saya punya editor. Tidak hanya itu memiliki garis bungkus, itu memiliki lekukan garis bungkus , yang (jika layar dikatakan 100 karakter lebar) akan menyebabkan

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

muncul sebagai

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut 
    labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco 
    laboris nisi ut aliquip ex ea commodo consequat.

atau dengan level indentasi apa pun yang ditetapkan sebagai default untuk bahasa saat ini.

Garis lebih lebar dari layar saya tidak pernah membuat kode lebih mudah dibaca dibandingkan kode lekukan-lekukan manual.

sunting: ooooh, saya tahu jawaban ini tidak akan populer :)

Tentu saja tidak. Ada alasan mengapa surat kabar dan majalah menggunakan kolom. Keterbacaan adalah faktor penting. Saat membaca mata kita memindai ke bawah dengan gerakan sisi ke sisi yang relatif sedikit. Efeknya adalah memungkinkan mata kita untuk memindai apa yang kita baca dengan cepat.

Bahkan ketika terlihat di kolom layar lebar memaksa mata kita untuk memindai bolak-balik dengan cepat. Saat memindai kembali kita tidak benar-benar memahami apa pun. Ini akan memperlambat membaca dan pemahaman secara signifikan. Efeknya mirip dengan printer mekanik lama. Ini sering membutuhkan beberapa karakter null untuk dimasukkan setelah carriage return untuk memberikan waktu bagi carriage atau print head untuk memposisikan ulang untuk baris berikutnya.

Selain itu, tata letak vertikal biasanya dilakukan dengan cara mengklarifikasi pengelompokan konten di telepon. Ini biasanya hanya berlaku untuk kondisi logika majemuk. Rumus panjang mungkin lebih terstruktur sebagai serangkaian pernyataan. (Pengoptimal akan memperbaiki overhead tambahan apa pun, dan beberapa pengoptimal akan menyerah atau berkinerja buruk pada formula kompleks.)

Pengidentifikasi dengan banyak titik yang membutuhkan garis besar menunjukkan teknik pengkodean yang harus diperbaiki.

Roda mouse memudahkan untuk menggulir dengan cepat secara vertikal ... menggulir secara horizontal terlalu mahal dibandingkan.

Hindari pengguliran horizontal.

~ Panduan Interaksi Pengalaman Pengguna Windows hal. 112

Iya.

Orang Inggris membaca dari kiri ke kanan sehingga bergulir konstan = Tidak produktif

Untuk alasan ini saya selalu mengaktifkan bungkus kata dengan mesin terbang garis visual dalam IDE saya.