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


159

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.


Semua jawaban cukup banyak menyatakan apa yang ingin saya tambahkan. Untuk memberi Anda contoh kehidupan nyata - Saya punya x61, resolusinya adalah 1024x768. Ketika saya di jalan, saya tidak memiliki monitor mewah saya. Membuka kode di IDE saya sangat merepotkan ketika melebihi aturan ini.
Hingga


Bahkan jika Anda memiliki 3 monitor. Ini bukan alasan untuk menggelengkan kepala kanan ke kiri dan ke belakang. Selama-lamanya. Ah-ha-ha. Sebenarnya mata bergerak lebih cepat dari kepala. Apakah Anda tahu tentang kolom di koran? Alasan lebarnya adalah kenyamanan mata / kepala / pria.
Ivan Black

Jawaban:


258

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 .


7
Mereka mungkin "sebagian besar sudah pergi", tetapi tidak sepenuhnya. Saya cenderung bekerja dengan dua pengaturan berbeda: 1) di jendela ssh yang terhubung ke mesin jarak jauh. yang lebar 80 karakter secara default. dan 2) Di Visual Studio, dengan dua panel berdampingan sehingga saya dapat melihat file header dan cpp pada saat bersamaan.
Enno

10
@steffenj: Sebenarnya, buku cenderung memotret sekitar 66 karakter per baris (walaupun ini agak bervariasi tergantung pada parameter lain) karena garis yang lebih panjang memang membuat membaca lebih sulit. Panjang garis kode maksimum dapat diperdebatkan, tetapi 80 nyaman untuk alasan historis dan praktis.
Steve S

70
Masalahnya adalah dengan memaksa orang untuk menjaga garis pendek, mereka cenderung menggunakan nama yang kurang bermakna ..
Ian Ringrose

4
Saya menemukan pernyataan tentang keterbacaan yang cukup menarik, karena hal yang sangat saya benci tentang artikel pemrograman dicetak / buku / ... adalah, bahwa garis pendek yang digunakan untuk contoh kode sangat sulit untuk dibaca. Mungkin masuk akal untuk memindahkan sesuatu ke baris baru, tetapi pengelompokan harus dilakukan secara logis, membedah ekspresi secara rekursif, bukan karena perangkat output secara tidak sengaja mencapai batasannya. TKI, saya menemukan bahwa perangkat yang memaksakan pembatasan sempit seperti itu tidak cocok untuk menampilkan kode.
Chris Lercher

4
Saya pikir masalah dengan penegak 80-kolom adalah bahwa mereka lupa bahwa kode bukannya tumbuh ke arah vertikal. Anda mendapatkan masalah yang sama, tetapi dalam arah vertikal DAN atas kode modern ini tampak mengerikan ketika Anda harus memecah pernyataan tunggal lebih dari dua atau kadang-kadang hingga empat atau lima baris. Ini TIDAK lebih mudah dibaca. Dengan kode modern yang saya maksud adalah nama variabel deskriptif dan pewarisan kualifikasi, ruang nama, kelas, dll. Harap hentikan 80 kolom nonsese, gunakan akal sehat sebagai gantinya. 120 lebih baik, tetapi juga seharusnya tidak menjadi aturan.
Larswad

79

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:

Kartu punch FORTRAN


59

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


1
Batas karakter tidak memberi tahu Anda DI MANA Anda harus membagi satu baris kode, tetapi KAPAN
gztomas

Tidak, bukan. Jika Anda menulis lebih dari 80 karakter baris, Anda mungkin sudah memiliki masalah dalam kompleksitas ekspresi atau strategi penamaan. Seperti yang telah disebutkan orang lain, keterbacaan menjadi perhatian utama dan kecepatan membaca mulai turun di atas 60-66 karakter (tipografi, berdasarkan fisiologi manusia).
sola

@ola Komentar Anda muncul di sini dengan 98 karakter, dan itu adalah bahasa non-pribumi yang padat (bagi saya) untuk dipahami. Sepenuhnya terbaca. Kode dengan 3-4 indentasi, marker sintaks, dll. Bahkan lebih mudah.
viyps

Saya tidak sengaja menurunkan jawaban ini dan tidak dapat lagi membatalkannya. :(
Andy

35

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.


14
Tidak saat Anda menambahkan indentasi ke dalam campuran. Jika Anda menggunakan 4 spasi per indent, dan Anda berada pada sesuatu seperti, namespace-> class-> method-> if-> untuk, itu 1/5 dari ruang yang Anda hancurkan.
TraumaPony

Anda selalu bisa menetapkan aturan pada 80 karakter dari indentasi. Dengan begitu mata bisa dengan mudah mengikutinya.
Vincent McNabb

Kadang-kadang, (tapi tidak selalu) saya berharap. Net memiliki penamaan otomatis sehingga Anda tidak perlu mendefinisikan namespace dalam file. Itu serius mengacaukan pelurusan kode Anda. jika Anda ingin ruang nama bersarang, Anda memiliki masalah yang sangat besar.
Kibbee

13
Namun, membaca prosa tidak sama dengan membaca kode.
Atario

3
+1 untuk koran, contoh yang bagus. @Atario, membaca kode BAIK sangat mirip dengan membaca prosa.
Todd Chaffee

23

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.


8
Dengan mengatakan bahwa hanya ada sedikit perbedaan dari baris ke baris, Anda juga mengatakan, bahwa ada banyak kode yang berlebihan. Menghapus beberapa yang secara signifikan dapat mengurangi jumlah kolom dan masih disejajarkan secara vertikal.
foraidt

@ mxp: disetujui. Jika ada cara penulisan yang lebih ringkas di atas, saya akan tertarik melihatnya.
Sam Hasler

Saya setuju dengan ide umum, tetapi contohnya ... Bagaimana dengan ini: switch (...) {case ... BL: dxDir = - 1; dyDir = - 1; istirahat; huruf ... BR: dxDir = +1; dyDir = - 1; istirahat; ...} ... ["X"] = pt1.x + dxDir * Rad ... X; ... ["Y"] = pt1.y + dyDir * Rad ... Y;
Yarik

38
Fakta bahwa saya perlu menggulir yang pertama dari dua contoh secara horizontal membuktikan pint tentang garis yang lebih pendek menjadi lebih baik :-)
Enno

1
Saya tidak mengerti kebencian untuk menggulir? Itu pendapat umum, dan saya tidak mengatakan itu salah, saya hanya tidak memahaminya. Terutama jika Anda berada di editor kode, Anda bahkan tidak perlu menggerakkan tangan Anda dari keyboard untuk sampai ke mouse - tepat (ctrl+)arrowatau tekanend
KOGI

21

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


16

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.


14

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.


Ada studi yang menunjukkan bahwa orang dapat membaca dan mengikuti x jumlah karakter / kata, sebelum mereka kehilangan jejak. Saya pikir 80 ada di sana di suatu tempat. Saya tidak punya sumber untuk mendukung itu.
Hingga

Ya, saya pikir benar, ini bukan tentang menjaga garis pendek seperti tentang menjaga garis bersih / singkat / mudah dibaca / dimengerti.
KOGI

Jika Anda memiliki (panggilan yang membutuhkan sejumlah parameter), Anda tetap harus melakukan beberapa refactoring.
Zarremgregarrok

@Zarremgregarrok Saya telah melihat beberapa daftar parameter yang sangat panjang di Microsoft API.
Loren Pechtel

@LorenPechtel Apakah itu membuatnya ditulis dengan baik?
Zarremgregarrok

8

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).


7

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 .


Terima kasih sudah mengatakan ini! Monitor besar lebih merupakan alasan untuk batas garis 80, sehingga Anda dapat memuat lebih banyak jendela berdampingan. Belum lagi bahwa kadang-kadang bisa mencetak kode sumber (di atas kertas). Atau rekatkan cuplikan ke dokumen lain.
Dreeves

7

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.


5
Saya bukan penggemar scrollbar horizontal
bryc

9
Saya terkejut tidak ada yang mengatakan ini, mengingat bahwa saya beberapa tahun terlambat untuk diskusi ini, tapi saya pikir baris baru (mungkin dengan indentasi untuk kejelasan) tepat sebelum kata kunci "extends" dan / atau "implement" masih akan menghasilkan sangat kode yang bisa dibaca.
mtraceur

2
Saya suka fakta bahwa ia mengatakan "ini sangat mudah dibaca pada satu baris" sementara pada saat yang sama saya tidak dapat membaca seluruh potongan kode karena meluap ruang horisontal di browser. Poin tidak terbukti.
oligofren

6

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.


6

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?"


1
Saya akan hidup dengan 80 karakter ketika saya bisa memiliki 2spc tabstop. Lebih baik lagi, sebenarnya menggunakan tab untuk indentasi, persyaratannya adalah ketika tabsize = 2, cocok dalam 80 kolom, gunakan 4 sebagian besar waktu untuk keterbacaan yang lebih baik. Dengan begitu ketika Anda benar-benar harus tersedak hingga 80 kolom Anda bisa, tetapi dengan harga.
Joshua

5

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.


3
Bagaimana dengan membaca kode dengan banyak panggilan fungsi? Tentunya ada kompromi antara kedua pendekatan ini ...
Zsolt Török

5

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 .


5

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.


5

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).


4

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


4

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.


4

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.


Ide yang sangat buruk ketika Anda ingin menggunakan 'indentasi' dan font monospace.
Bersaelor

2
@Bersaelor Tidak, itu berfungsi dengan baik ketika Anda selalu membuat indentasi menggunakan tab saja dan mengatur lebar tab dengan benar (lebar 4 monospasi mungkin 7 proporsional). Lekukan bekerja, Anda tidak bisa melakukan seni ASCII, tapi saya tidak berpikir seni ASCII termasuk dalam kode.
maaartinus

Secara pribadi, saya cukup di sisi yang berlawanan ketika pemrograman. Saya menemukan kode proporsional sangat sulit dibaca. Kadang-kadang, saya bahkan mengkonfigurasi IDE untuk menggunakan font monospace (ya, termasuk menu).
Sebastian Mach

2

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.


2

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.


2

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 katateks alternatif

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.

1

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 cukup yakin itu dari hari-hari ketika layar mode teks lebar 80 karakter.
TraumaPony

1

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.


1

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.


0

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.


0

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.)


0

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.


0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.