Penamaan deskriptif vs. 80 baris karakter [tertutup]


17

Saya sering mendengar dua praktik pemrograman yang berharga ini: (1) baris kode harus 80 karakter atau kurang dan (2) menggunakan nama deskriptif untuk variabel, metode, kelas, dll. Saya mengerti alasan kedua kata nasihat ini, namun , mereka tampaknya sering menjadi pengorbanan satu sama lain. Jika saya menyimpan kode saya di bawah 80 karakter / baris saya akhirnya menggunakan nama yang kurang deskriptif (khususnya dalam Python di mana setiap lekukan dihitung sebagai 4 karakter) tetapi jika saya menggunakan nama yang lebih deskriptif, saya berakhir dengan garis lebih dari 80 karakter.

Jadi, pertanyaan saya adalah manakah dari dua nasihat ini yang lebih penting untuk dipatuhi jika pilihan harus diambil? Saya ingin tahu ini sebagai programmer (hobi) independen, tetapi yang lebih penting dari sudut pandang seorang insinyur perangkat lunak yang bekerja untuk perusahaan yang lebih besar.


4
@BillyONeal Dengan layar besar, 120 :)
BЈовић

4
Saya pikir saya perlu setidaknya 130
9dan

8
Saya lebih suka 80, karena saya kemudian dapat dengan mudah membuka 2 file berdampingan di notebook saya.
Honza Brabec

5
Baris yang lebih panjang dari 80 karakter cenderung tidak dapat dibaca. Jadi 80 adalah batas yang baik. Deskriptif tidak perlu terlalu bertele-tele. Dan itu tergantung dari ruang lingkup: nama kecil variabel pendek ruang lingkup, nama besar ruang lingkup panjang. Dan tentu saja menghindari variabel dengan cakupan besar. Jika Anda menggunakan bahasa fungsional dan pecahkan kode Anda dalam fungsi yang lebih kecil ketika indentasi terlalu dalam -> lingkup sangat kecil == varnames pendek. Nama fungsi mirip tetapi biasanya sedikit lebih lama karena cakupannya lebih besar.
Peer Stritzinger

4
@ ott--: Pernahkah Anda melihat editor, yang benar-benar dapat mematahkan garis panjang, menurut sintaks C ++, dan menyajikan kelanjutan indentasi satu tingkat lebih dari awal? Kalau tidak, saran seperti itu tidak berguna.
Jan Hudec

Jawaban:


34

Jaga sedikit indentasi Anda, nama Anda deskriptif, dan jangan takut untuk melanggar batas.

Jaga sedikit indentasi Anda.

Seringkali ketika saya menemukan diri saya dalam pergulatan antara indentasi dan penamaan deskriptif, saya mundur selangkah dan melihat level indentasi saya. Jika Anda membuat indentasi lebih dari 3 atau 4 level (2 level otomatis dan tidak dapat dihindari dalam banyak kasus. Baca: definisi metode kelas), Anda mungkin ingin merestrukturisasi kode Anda, mengabstraksikan fungsionalitas menjadi fungsi atau metode.

Nama Anda deskriptif

Anda harus selalu menjaga agar nama Anda tetap deskriptif. Nama deskriptif membuat kode dokumentasi sendiri. Anda dapat mencoba mempersingkat nama dalam beberapa kasus, tetapi keterbacaan lebih dulu.

Jangan takut untuk melanggar batas

Sial terjadi. Jika Anda menggunakan lebih dari 80 karakter, dan bagaimanapun Anda tidak melihat untuk mendapatkan kembali ruang apa pun di baris - pecahkan. Sebagian besar bahasa tidak peduli dengan jeda baris, jadi pisahkan garis menjadi beberapa. Jangan hanya memilih lokasi acak. Biarkan semuanya dikelompokkan secara logis, dan indentasi tingkat lain ketika Anda benar-benar melanggar batas.


3
Perlu dicatat, bahwa nama deskriptif tidak sama dengan nama panjang. Menghindari pengulangan hal-hal yang dapat dengan mudah dilihat dari konteks dan beberapa singkatan yang dipilih dengan hati - hati (hanya untuk konsep yang sangat umum) dapat pergi jauh ke arah nama deskriptif pendek.
Jan Hudec

18

Mengapa tidak keduanya?

Pertama-tama, "deskriptif" dan "verbose" tidak sama. Misalnya, jika Anda menulis loop lokal, iadalah nama variabel yang sangat bagus untuk variabel loop; current_iteration_index, sementara bisa dibilang lebih deskriptif dan jelas lebih bertele-tele, jauh lebih buruk dan tidak menambahkan informasi sama sekali, karena penggunaan isebagai variabel loop cukup banyak diterima secara universal, dan tidak ada arti lain iselain itu.

Nama variabel yang baik bersifat deskriptif, karena seorang programmer yang akrab dengan idiom bahasa dan konvensi basis kode dapat dengan mudah menebak apa peran mereka, tetapi mereka juga cukup ringkas untuk membuat segala sesuatunya tetap kompak.

Batas 80 karakter, walaupun awalnya merupakan konsekuensi dari keterbatasan teknis terminal teks tahun 1970-an, masih dihargai oleh banyak orang saat ini, dan meskipun masih ada alasan teknis (panjang garis maksimum dalam beberapa protokol jaringan, terutama terkait dengan e-mail), alasan yang lebih menarik adalah alasan psikologis dan sosial. Ternyata panjang garis di sekitar tanda 66 membuat pengalaman membaca yang paling nyaman untuk prosa bahasa alami (ukuran font yang menarik tidak membuat banyak perbedaan, dan akibatnya, tidak juga ukuran layar atau kertas); Batas garis 80 karakter cukup dekat dengan itu, tetapi karena sebagian besar potongan kode biasanya menjorok setidaknya satu atau dua level (yang berarti antara 4 dan 16 karakter, tergantung pada pengaturan lekukan),

Efek lain dari berpegang pada garis 80-karakter adalah bahwa itu adalah indikator yang cukup bagus ketika semuanya terlalu rumit. Garis yang panjang biasanya disebabkan oleh salah satu dari yang berikut:

  • Fungsinya dengan daftar panjang argumen; ini bukan hal yang baik untuk dimiliki, karena mereka menghambat keterbacaan dan dapat dengan mudah menyebabkan bug halus, misalnya ketika orang bertukar urutan argumen dengan cara yang tidak ditangkap oleh kompiler.
  • Ekspresi kompleks, sering ditemukan dalam kondisi (misalnya if ((user.isLoggedIn && user.hasPermission(page.getRequiredPermission()) && !user.isBanned) || page.getRequiredPermission() == null)); ini juga biasanya agak sulit untuk diuraikan, dan kode harus ditulis ulang menjadi sesuatu yang lebih terstruktur. Kemungkinan besar, ekspresi itu terlalu banyak dan harus difaktorkan ke dalam metode atau fungsi.
  • Literal panjang yang digunakan dalam pemanggilan fungsi atau ekspresi, mis print(translate(LANG_EN, LANG_ES, "This is the home page. Feel welcome to click around and see what we have."));. Pindahkan literal ke dalam variabel atau konstan; mungkin masih melebihi panjang garis, tetapi jika Anda melakukannya secara konsisten, pembaca setidaknya dapat dengan aman mengabaikan bagian garis yang tidak terlihat, dengan asumsi bahwa hanya sisa dari literal yang mengikuti. Atau lebih baik lagi, pindahkan literal keluar dari kode dan ke penyimpanan data eksternal (file, database, apa pun).
  • Pernyataan yang sangat bersarang, misalnya enam tingkat ifpernyataan dalam metode kelas (yaitu 32 kolom lekukan untuk pengaturan tipikal). Sekali lagi, sarang yang dalam membuat kode yang rumit dan sulit dibaca, dan harus dihindari seperti wabah - sederhananya, sarang yang dalam meluap dari tumpukan otak manusia saat membaca.

Semua ini pada akhirnya adalah gejala dari hal-hal yang Anda tidak akan miliki dalam basis kode Anda dalam jangka panjang, dan menegakkan batas 80 karakter adalah cara yang bagus dan sederhana yang membantu menjaga kompleksitas turun dan keterbacaan tetap tinggi. (Bukan berarti Anda tidak dapat menulis kode yang benar-benar tidak dapat dibaca dalam 80 kolom: berbagai kontes kode sesuatu yang membingungkan adalah contoh-contoh yang jelas).


1
+1: Jawaban yang bagus kecuali saya tidak setuju dengan memindahkan literal dari kode. Ketika Anda tahu literal mana yang Anda cari, Anda dapat melihatnya dalam sumber daya atau kode dengan sama baiknya, tetapi ketika Anda bekerja dengan kode tersebut dan perlu memodifikasi literal, harus memburunya dalam file terpisah cukup mengganggu. Perhatikan juga, bahwa semua bahasa memiliki beberapa cara untuk memecah literal menjadi beberapa baris, itulah yang akan saya lakukan dalam kasus tersebut.
Jan Hudec

Tentu saja kalimat yang digunakan sebagai contoh literal panjang tidak memiliki tempat tinggal dalam kode sumber. Hal-hal seperti ini masuk dalam templat halaman. Tetapi untuk hal-hal seperti pesan kesalahan, saya lebih suka menyimpannya dengan kode yang memancarkannya.
Jan Hudec

@ JanHudec: Tentu, memindahkan literal ke file data tidak selalu masuk akal. Saya berbicara tentang literal yang terlalu panjang, dan dengan itu, saya jarang melihat suatu kesempatan di mana mendefinisikannya di tempat lain akan membuat kode lebih buruk: panjang teks mengganggu membaca, sedangkan artinya bisa dengan mudah diringkas menjadi nama konstan atau variabel, yang kemudian Anda tentukan di tempat lain. Pesan kesalahan adalah panggilan penilaian, saya kira.
Pengamat

16

Penamaan deskriptif oleh JAUH lebih penting. Di sebagian besar antarmuka kita dapat menggulir untuk melihat garis yang lebih panjang. Dalam hal apa pun sistem tidak dapat membantu Anda menerjemahkan variabel dan fungsi yang tidak disebutkan namanya.


2
Ini. Berhenti memecah garis pada karakter X, biarkan IDE mengatasinya. Jika tidak, Anda mengganggu semua pengguna lain (termasuk Anda di masa depan!) Yang layar / IDE dapat menangani 2 * X karakter dengan kode yang tidak muat di satu halaman lagi.
Konerak

4
Pertanyaan itu secara implisit tentang nama panjang . Dan saya tidak setuju bahwa nama harus panjang - sebagian besar waktu harus pendek . Deskriptif, nama panjang dapat membuat kode lebih sulit dibaca daripada nama yang sedikit kurang deskriptif tapi lebih pendek! (Garis yang terlalu panjang biasanya sulit dibaca.)
Konrad Rudolph

4
Saya tidak setuju. Jika saya tidak dapat melihat kode sekaligus, sulit untuk membaca, tidak peduli seberapa deskriptif namanya.
Jan Hudec

4

80 karakter per baris tidak sulit untuk dipenuhi walaupun penamaannya panjang karena ada banyak cara untuk memecah satu baris kode panjang menjadi beberapa kode pendek, misalnya, saya dapat memecah pernyataan kondisi dalam C menjadi beberapa baris agar muat kurang dari 40 karakter,

if ( a == b || c == d  || d == e
    || c == e || c == a || c == k
    || c == l)

Anda juga dapat membagi satu baris fungsi panggilan menjadi beberapa baris juga.

Oleh karena itu, kedua aturan penamaan deskriptif dan 80 baris karakter tidak memiliki kontradiksi, mereka dapat hidup berdampingan untuk meningkatkan keterbacaan.


2
Apakah 80 karakter benar-benar meningkatkan keterbacaan? Layar apa yang tidak dapat dengan mudah dilakukan 120 hari ini?
Billy ONeal

7
@BillyONeal lebih mudah untuk memindai lebih dari 80 lebar daripada lebih dari 120 lebar
ratchet freak

2
surat kabar terbagi menjadi beberapa kolom, dan Anda dapat memiliki informasi lebih lanjut dari ux ux.stackexchange.com/questions/3618/…
neo

1
Memecah kondisi logika meningkatkan pembacaan ketika garis putus sesuai dengan struktur kondisi, tetapi tidak harus jika mereka hanya sesuai dengan batas sewenang-wenang.
mikołak

1
@ BillyONeal: sebagian besar layar dapat melakukan 120, tetapi hampir tidak ada yang bisa melakukan 240. Atau apakah Anda tidak pernah membandingkan perbedaan?
Hubert Kario

0

Batas 80 adalah sesuatu yang seharusnya ditingkatkan sejak lama. Perhatikan bahwa batas ini digunakan sejak usia ketika panjang setiap pengenal dibatasi hingga 8 karakter dan hanya satu font pada layar / printer. Tidak ada kemungkinan untuk mengubah ukuran font.

Ya Tuhan, kami memiliki teknologi layar dan pencetakan yang berbeda sekarang. Kami memiliki bahasa pemrograman yang sangat berbeda. Tidak ada alasan untuk menggunakan 80 karakter lagi. Tingkatkan setidaknya 120 karakter.

Bahkan saat itu seharusnya tidak menjadi batas yang sulit. Anda pergi satu karakter melewati garis? Yah, tidak ada yang terjadi!

Edit:

Jawaban terperinci tentang sejarah batas 80-char

Karakter Per Baris di Wikipedia

Sebuah studi di Wichita State University menemukan bahwa CPL hanya memiliki efek kecil pada keterbacaan, termasuk faktor kecepatan dan pemahaman. Ketika ditanya tentang preferensi, 60% responden mengindikasikan preferensi untuk jalur terpendek (35 CPL) atau terpanjang (95 CPL) yang digunakan dalam penelitian ini. Pada saat yang sama, 100% responden memilih salah satu dari jumlah ini sebagai yang paling tidak diinginkan.


4
Tidak, batasnya pasti tidak harus ditingkatkan. Karena sama sekali tidak ada hubungannya dengan teknologi layar dan pencetakan, hanya dengan fakta bahwa 80 karakter per baris adalah maksimum mata manusia dapat dengan nyaman memindai (66 karakter dianggap lebar garis optimal, kurang dalam pencetakan multi-kolom). Ngomong-ngomong berarti sebagian besar buku memiliki sedikit kurang dari 80 kolom untuk sampel kode.
Jan Hudec

3
@JanHudec Memiliki segalanya dengan teknologi layar / pencetakan. Rujuk ke programmers.stackexchange.com/questions/148677/… . Keputusan untuk menggunakan 80 karakter murni bersejarah, bukan berdasarkan penelitian. Bisakah Anda menambahkan tautan ke studi untuk mengonfirmasi pendapat Anda?
Sulthan

Pertanyaan lain sudah mendapatkan tautan UX ini di komentarnya; referensi lebih lanjut di sana. Sementara angka 80 itu sendiri adalah kebetulan bersejarah, angka ini secara kasar diturunkan dari jumlah pemogokan per baris pada mesin tik, yang secara kasar diturunkan dari lebar cetak kolom tunggal dan rata-rata 66 huruf sudah lama menjadi tradisi lama untuk itu.
Jan Hudec
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.