Apakah ada alasan yang sah untuk menerapkan lebar maksimum 80 karakter dalam file kode, hari ini dan usia ini? [Tutup]

Serius. Pada monitor 22 ", hanya mencakup mungkin seperempat layar. Saya perlu amunisi untuk menurunkan aturan ini.

Saya tidak mengatakan bahwa seharusnya tidak ada batasan; Saya hanya mengatakan, 80 karakter sangat kecil.

Saya pikir praktik menjaga kode ke 80 (atau 79) kolom pada awalnya dibuat untuk mendukung orang mengedit kode pada terminal bodoh 80-kolom atau pada cetakan 80-kolom. Persyaratan itu sebagian besar sudah hilang sekarang, tetapi masih ada alasan yang sah untuk mempertahankan aturan 80 kolom:

• Untuk menghindari pembungkus saat menyalin kode ke email, halaman web, dan buku.
• Untuk melihat beberapa jendela sumber berdampingan atau menggunakan penampil beda berdampingan.
• Untuk meningkatkan keterbacaan. Kode sempit dapat dibaca dengan cepat tanpa harus memindai mata Anda dari sisi ke sisi.

Saya pikir poin terakhir adalah yang paling penting. Meskipun tampilan telah tumbuh dalam ukuran dan resolusi dalam beberapa tahun terakhir, mata belum .

Asal usul pemformatan teks 80 kolom lebih awal dari terminal 80 kolom - kartu punch IBM dimulai pada tahun 1928 ! Ini mengingatkan kita pada kisah (apokrif) bahwa ukuran kereta api AS ditentukan oleh lebar roda kereta di Inggris Britania.

Aku kadang-kadang menemukan sebuah konstriksi sedikit, tapi masuk akal untuk memiliki beberapa batas standar, sehingga 80 kolom itu.

Inilah topik yang sama yang dicakup oleh Slashdot .

Dan inilah Pernyataan Fortran sekolah tua:

80 karakter adalah batas yang konyol hari ini. Pisahkan baris kode Anda di tempat yang masuk akal, tidak sesuai dengan batas karakter sembarang.

Anda hanya harus melakukannya demi semua orang yang tidak memiliki monitor layar lebar 22 inci. Secara pribadi, saya bekerja pada monitor 17: 4 4 inci, dan saya menemukan bahwa lebih dari cukup lebar. Namun, saya juga punya 3 monitor itu, jadi saya masih punya banyak ruang layar yang bisa digunakan.

Bukan hanya itu, tetapi mata manusia sebenarnya memiliki masalah membaca teks jika garisnya terlalu panjang. Terlalu mudah tersesat di jalur mana Anda berada. Surat kabar berukuran 17 inci (atau semacamnya), tetapi Anda tidak melihat mereka menulis sepanjang halaman, begitu pula untuk majalah dan barang cetakan lainnya. Ini sebenarnya lebih mudah dibaca jika Anda menjaga kolom tetap sempit.

Ketika Anda memiliki urutan pernyataan yang diulang dengan variasi kecil, akan lebih mudah untuk melihat persamaan dan perbedaan jika mereka dikelompokkan ke dalam garis sehingga perbedaan tersebut selaras secara vertikal.

Saya berpendapat bahwa yang berikut ini jauh lebih mudah dibaca daripada jika saya membaginya menjadi beberapa baris:

switch(Type) {
case External_BL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_BR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case External_TR:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case External_TL:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_BR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y + RadialClrY;    break;
case Internal_TR:   mpstrd["X"] = ptDig1.x - RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
case Internal_TL:   mpstrd["X"] = ptDig1.x + RadialClrX;    mpstrd["Y"] = ptDig1.y - RadialClrY;    break;
}

Pembaruan: Dalam komentar, disarankan bahwa ini akan menjadi cara yang lebih ringkas untuk melakukan hal di atas:

switch(Type) {
  case External_BL: dxDir = - 1; dyDir = - 1; break;
  case External_BR: dxDir = + 1; dyDir = - 1; break;
  case External_TR: dxDir = + 1; dyDir = + 1; break;
  case External_TL: dxDir = - 1; dyDir = + 1; break;
  case Internal_BL: dxDir = + 1; dyDir = + 1; break;
  case Internal_BR: dxDir = - 1; dyDir = + 1; break;
  case Internal_TR: dxDir = - 1; dyDir = - 1; break;
  case Internal_TL: dxDir = + 1; dyDir = - 1; break;
}
mpstrd["X"] = pt1.x + dxDir * RadialClrX;
mpstrd["Y"] = pt1.y + dyDir * RadialClrY; 

meskipun sekarang cocok dalam 80 kolom saya pikir poin saya masih berdiri dan saya baru saja mengambil contoh yang buruk. Itu masih menunjukkan bahwa menempatkan beberapa pernyataan pada satu baris dapat meningkatkan keterbacaan.

Mencetak font monospace pada ukuran standar adalah (pada kertas A4) 80 kolom dengan 66 baris.

Saya menggunakan keuntungan dari layar yang lebih besar untuk memiliki beberapa bagian kode di sebelah satu sama lain.

Anda tidak akan mendapatkan amunisi dari saya. Bahkan, saya benci melihatnya berubah karena dalam keadaan darurat saya masih melihat kasus-kasus langka di mana saya perlu mengubah kode dari konsol teks.

Baris super panjang lebih sulit dibaca. Hanya karena Anda bisa mendapatkan 300 karakter pada monitor Anda tidak berarti Anda harus membuat garis yang panjang. 300 karakter juga terlalu rumit untuk pernyataan kecuali Anda tidak punya pilihan (panggilan yang membutuhkan banyak parameter.)

Saya menggunakan 80 karakter sebagai aturan umum tetapi saya akan melangkah lebih jauh jika menegakkannya berarti menempatkan garis terputus di lokasi yang tidak diinginkan.

Satu-satunya hal yang saya tegakkan untuk tetap dalam 80 karakter adalah komentar saya.

Secara pribadi ... Saya mencurahkan seluruh kekuatan otak saya (yang ada sedikit) untuk pengkodean yang benar, sungguh menyebalkan harus kembali dan memecah semuanya pada batas 80 karakter ketika saya bisa menghabiskan waktu saya untuk fungsi berikutnya . Ya, Resharper dapat melakukannya untuk saya, saya kira, tetapi kemudian sedikit membuat saya takut bahwa produk pihak ketiga membuat keputusan tentang tata letak kode saya dan mengubahnya ("Tolong jangan pecah kode saya menjadi dua baris HAL. HAL?" ).

Yang mengatakan, saya bekerja pada tim yang cukup kecil dan semua monitor kami cukup besar sehingga mengkhawatirkan apa yang mengganggu sesama programmer saya tidak menjadi masalah besar sejauh itu.

Tampaknya beberapa bahasa mendorong garis kode yang lebih panjang demi lebih banyak keuntungan (tulisan singkat jika kemudian pernyataan).

Saya memiliki dua monitor 20 "1600x1200 dan saya tetap pada 80 kolom karena memungkinkan saya menampilkan beberapa jendela editor teks secara berdampingan. Menggunakan font '6x13' (font trad. Xterm) 80 kolom membutuhkan 480 piksel ditambah bilah gulir dan batas jendela. Ini memungkinkan seseorang untuk memiliki tiga jendela dari jenis ini pada monitor 1600x1200. Pada windows font Lucida Console tidak akan cukup melakukan ini (ukuran minimum yang dapat digunakan adalah lebar 7 piksel) tetapi monitor 1280x1024 akan menampilkan dua kolom dan monitor 1920x1200 seperti HP LP2465 akan menampilkan 3. Ini juga akan meninggalkan sedikit ruang di samping untuk berbagai penjelajah, properti, dan jendela lain dari Visual Studio.

Selain itu, baris teks yang sangat panjang sulit dibaca. Untuk teks yang optimal adalah 66 karakter. Ada titik di mana pengidentifikasi yang terlalu lama mulai menjadi kontraproduktif karena membuat sulit untuk mengeluarkan kode secara koheren. Tata letak dan lekukan yang baik memberikan isyarat visual tentang struktur kode dan beberapa bahasa (Python datang ke pikiran) menggunakan lekukan secara eksplisit untuk ini.

Namun, pustaka kelas standar untuk Java dan .Net cenderung memiliki dominan pengidentifikasi yang sangat panjang sehingga orang tidak dapat selalu menjamin untuk dapat melakukan ini. Dalam hal ini, mengeluarkan kode dengan jeda baris masih membantu membuat struktur menjadi eksplisit.

Perhatikan bahwa Anda bisa mendapatkan font '6x13' versi windows Di Sini .

Kata orang, baris kode yang panjang cenderung rumit. Pertimbangkan kelas Java sederhana:

public class PlaintiffServiceImpl extends RemoteServiceServlet implements PlaintiffService {

Ini panjangnya 94 karakter dan nama kelasnya cukup pendek (menurut standar GWT). Akan sulit dibaca pada 2 baris dan sangat mudah dibaca pada satu baris. Menjadi pragmatis tentang hal itu dan dengan demikian memungkinkan "kompatibilitas mundur", saya akan mengatakan 100 karakter adalah lebar yang tepat.

Jawaban lain sudah merangkum semuanya dengan baik, tetapi juga patut dipertimbangkan ketika Anda mungkin ingin menyalin & menempelkan beberapa kode ke email, atau jika bukan kode maka beda.

Itu saat ketika memiliki "lebar maks" berguna.

Anda bukan satu-satunya orang yang akan mempertahankan kode Anda.

Orang berikutnya yang mungkin memiliki layar 17 "atau mungkin memerlukan font besar untuk membaca teks. Batasnya harus di suatu tempat dan 80 karakter adalah konvensi karena keterbatasan layar sebelumnya. Dapatkah Anda memikirkan standar baru (120) dan mengapa itu ide yang baik untuk menggunakan selain itu "itu yang cocok di monitor saya di font Xpt?"

Ingat, selalu ada pengecualian untuk setiap aturan sehingga Anda memiliki baris atau blok kode tertentu yang masuk akal menjadi lebih dari 80 karakter lalu menjadi pemberontak.

Tetapi luangkan waktu dulu untuk berpikir "apakah kode ini benar-benar seburuk itu tidak dapat hidup dalam 80 karakter?"

Dalam standar pengkodean Linux, mereka tidak hanya menjaga batas 80 karakter, tetapi mereka juga menggunakan lekukan 8 ruang.

Bagian dari alasannya adalah bahwa jika Anda pernah mencapai margin yang tepat, Anda harus mempertimbangkan untuk memindahkan level indentasi ke fungsi yang terpisah.

Ini akan membuat kode lebih jelas karena terlepas dari panjang lekukan, lebih sulit untuk membaca kode dengan banyak struktur kontrol bersarang.

Saya telah memperluas kode saya menjadi 100 karakter yang cocok dengan nyaman dalam kurang dari setengah layar saya di Macbook saya. 120 karakter mungkin adalah batas sebelum garis mulai menjadi terlalu panjang dan kompleks. Anda tidak ingin menjadi terlalu lebar jika tidak mendorong pernyataan majemuk dan struktur kontrol yang bersarang secara mendalam.

Margin yang tepat adalah cara alami untuk memberitahu Anda untuk melakukan metode refactoring tambahan .

Saya bertanya-tanya apakah ini dapat menyebabkan lebih banyak masalah di zaman sekarang ini. Ingatlah bahwa dalam C (dan mungkin bahasa lain) ada aturan untuk berapa lama nama fungsi bisa. Oleh karena itu, Anda sering melihat nama yang sangat sulit dipahami dalam kode C. Hal yang baik adalah bahwa mereka tidak menggunakan banyak ruang. Tetapi setiap kali saya melihat kode dalam beberapa bahasa seperti C # atau Java nama-nama metode sering sangat panjang, yang membuatnya hampir mustahil untuk menjaga kode Anda sepanjang 80 karakter. Saya rasa 80 karakter tidak valid hari ini, kecuali jika Anda harus dapat mencetak kode, dll.

Sebagai penulis pedoman pengkodean untuk atasan saya, saya telah menaikkan panjang garis dari 80 menjadi 132. Mengapa nilai ini? Nah, seperti yang ditunjukkan orang lain, 80 adalah panjang dari banyak terminal perangkat keras lama. Dan 132 juga! Ini adalah garis lebar ketika terminal dalam mode lebar . Printer apa pun juga dapat membuat cetakan dalam mode lebar dengan font yang kental.

Alasan untuk tidak menginap di 80 adalah karena saya lebih suka

• lebih suka nama yang lebih panjang dengan arti untuk pengidentifikasi
• tidak repot dengan typedef untuk struct dan enum di C (mereka BAD, mereka menyembunyikan informasi yang berguna! Tanyakan Peter van der Linden di "Deep C Secrets" jika Anda tidak percaya), sehingga kode memiliki lebih struct FOO func(struct BAR *aWhatever, ...)dari kode fanatik typedef .

dan di bawah aturan ini hanya 80 karakter / garis menyebabkan garis jelek membungkus lebih sering daripada yang saya anggap dapat diterima (kebanyakan dalam prototipe dan definisi fungsi).

Seperti yang dikatakan orang lain, saya pikir yang terbaik untuk (1) mencetak dan (2) menampilkan banyak file berdampingan secara vertikal.

Saya ingin membatasi lebar saya hingga 100 karakter atau lebih untuk memungkinkan dua editor SxS pada monitor layar lebar. Saya tidak berpikir bahwa ada alasan bagus untuk batas tepat 80 karakter lagi.

Gunakan font proporsional.

Aku serius. Saya biasanya bisa mendapatkan kesetaraan 100-120 karakter dalam satu baris tanpa mengorbankan keterbacaan atau kemampuan cetak. Bahkan lebih mudah dibaca dengan font yang bagus (mis., Verdana) dan pewarnaan sintaksis. Kelihatannya agak aneh selama beberapa hari, tetapi Anda dengan cepat terbiasa.

Saya mencoba untuk menjaga semuanya di dekat 80 karakter untuk alasan sederhana: terlalu banyak daripada itu berarti kode saya menjadi terlalu rumit. Nama properti / metode yang terlalu bertele-tele, nama kelas, dll. Menyebabkan kerugian yang sama banyaknya dengan yang singkat.

Saya terutama adalah pembuat kode Python, jadi ini menghasilkan dua set batasan:

1. Jangan menulis baris kode yang panjang
2. Jangan terlalu banyak indentasi

Ketika Anda mulai mencapai dua atau tiga tingkat indentasi, logika Anda menjadi membingungkan. Jika Anda tidak dapat menyimpan satu blok pada halaman yang sama, kode Anda menjadi terlalu rumit dan sulit untuk diingat. Jika Anda tidak dapat menyimpan satu baris dalam 80 karakter, baris Anda menjadi terlalu rumit.

Sangat mudah dalam Python untuk menulis kode yang relatif ringkas (lihat codegolf) dengan mengorbankan keterbacaan, tetapi bahkan lebih mudah untuk menulis kode verbose dengan mengorbankan keterbacaan. Metode penolong bukanlah hal yang buruk, tidak juga kelas penolong. Abstraksi berlebihan bisa menjadi masalah, tapi itu tantangan lain pemrograman.

Jika ragu dalam bahasa seperti C tulis fungsi pembantu dan sebariskan jika Anda tidak ingin overhead memanggil fungsi lain dan melompat kembali. Dalam kebanyakan kasus, kompiler akan menangani hal-hal secara cerdas untuk Anda.

Sudah ada banyak jawaban bagus untuk ini, tetapi perlu disebutkan bahwa dalam IDE Anda, Anda mungkin memiliki daftar file di sebelah kiri, dan daftar fungsi di sebelah kanan (atau konfigurasi lainnya).

Kode Anda hanyalah salah satu bagian dari lingkungan.

Saya kira tidak memberlakukan 80 karakter berarti akhirnya membungkus kata.
IMO, panjang apa pun yang dipilih untuk garis max-width tidak selalu sesuai dan pembungkus kata harus menjadi jawaban yang memungkinkan.
Dan itu tidak semudah kedengarannya.

Ini diimplementasikan dalam jedit _{(sumber: jedit.org )} yang menawarkan bungkus kata

Tapi itu sangat pahit dalam gerhana dari waktu looong ! (sejak 2003 sebenarnya), terutama karena bungkus kata untuk editor teks melibatkan:

• Informasi garis yang dibungkus untuk penampil teks, navigasi kode, penggaris vertikal.
• Informasi garis yang tidak dibungkus diperlukan untuk fungsi seperti garis goto, kolom garis penomoran, sorotan garis saat ini, menyimpan file.

Saya benar-benar mengikuti aturan yang sama untuk kode saya sendiri tetapi hanya karena mencetak kode ke halaman A4 - 80 kolom adalah tentang lebar yang tepat untuk ukuran font yang saya inginkan.

Tapi itu preferensi pribadi dan mungkin bukan yang Anda kejar (karena Anda ingin amunisi pergi ke arah lain).

Apa yang tidak Anda pertanyakan alasan di balik batas - serius, jika tidak ada yang bisa datang dengan alasan bagus mengapa begitu, Anda memiliki alasan yang baik untuk menghapusnya dari standar pengkodean Anda.

Saya berbeda berdampingan sepanjang hari dan saya tidak punya monitor 22 inci. Saya tidak tahu apakah saya akan melakukannya. Ini, tentu saja, tidak begitu menarik bagi pemrogram yang hanya menulis yang menikmati kode panah dan 300-baris char.

Ya, karena bahkan di zaman sekarang ini, sebagian dari kita melakukan pengkodean pada terminal (ok, kebanyakan emulator terminal), di mana layar hanya dapat menampilkan 80 karakter. Jadi, setidaknya untuk coding yang saya lakukan, saya sangat menghargai aturan 80 char.

Saya masih berpikir bahwa batasnya tidak terbatas pada bagian visual. Tentu, monitor dan resolusi cukup besar untuk menunjukkan lebih banyak karakter dalam satu baris saat ini, tetapi apakah itu meningkatkan keterbacaan?

Jika batas benar-benar ditegakkan, itu juga merupakan alasan yang baik untuk memikirkan kembali kode dan tidak menempatkan semuanya dalam satu baris. Ini sama dengan lekukan - jika Anda perlu banyak level kode Anda perlu dipikirkan kembali.

Mematahkan 80 karakter adalah sesuatu yang Anda lakukan saat coding, bukan sesudahnya. Sama dengan komentar, tentu saja. Sebagian besar editor dapat membantu Anda melihat di mana batas 80 karakter.

(Ini mungkin OT kecil, tetapi di Eclipse ada opsi yang memformat kode ketika Anda menyimpannya (sesuai dengan aturan apa pun yang Anda inginkan). Ini agak aneh pada awalnya, tetapi setelah beberapa saat Anda mulai menerima bahwa pemformatan tidak lebih di tangan Anda daripada kode yang dihasilkan.)

Jika kita memiliki salah satunya , kita tidak akan melakukan diskusi ini! ;-)

Tapi serius masalah yang diangkat orang dalam jawaban mereka cukup sah. Namun poster asli tidak menentang batas, hanya bahwa 80 kolom terlalu sedikit.

Masalah cuplikan kode email memiliki beberapa kelebihan. Tetapi mempertimbangkan hal-hal jahat yang dilakukan sebagian besar klien email terhadap teks yang telah diformat sebelumnya, saya pikir pembungkus baris hanyalah salah satu masalah Anda.

Sedangkan untuk pencetakan saya biasanya menemukan bahwa 100 karakter garis akan sangat nyaman masuk ke halaman yang dicetak.

Saya mencoba dan menjaga garis saya di bawah 80 kolom. Alasan terkuat adalah bahwa saya sering menemukan diri saya menggunakan grepdan lessuntuk menelusuri kode saya ketika bekerja di baris perintah. Saya benar-benar tidak suka terminal putus jalur sumber panjang (mereka tidak dibuat untuk pekerjaan itu). Alasan lain adalah bahwa saya merasa itu terlihat lebih baik jika semuanya sesuai dengan garis dan tidak rusak oleh editor. Misalnya memiliki parameter panggilan fungsi panjang baik disejajarkan di bawah satu sama lain dan hal-hal serupa.