Mengapa verbositas buruk untuk bahasa pemrograman? [Tutup]


98

Saya telah melihat banyak orang mengeluhkan verbositas dalam bahasa pemrograman. Saya menemukan bahwa, dalam beberapa batasan, semakin banyak bahasa pemrograman, semakin baik untuk dipahami. Saya pikir verbositas itu juga memperkuat penulisan yang lebih jelas APIuntuk bahasa itu.

Satu-satunya kelemahan yang dapat saya pikirkan adalah itu membuat Anda mengetik lebih banyak, tapi maksud saya, kebanyakan orang menggunakan IDE yang melakukan semua pekerjaan untuk Anda.

Jadi, Apa kemungkinan kerugian dari bahasa pemrograman verbose?


20
Sudahkah Anda mengkode di APL baru-baru ini?
SK-logic

5
Lihatlah Bahasa, Verbositas, dan Jawa oleh Dhanji R. Prasanna
Jeremy Heiler

67
"Seorang pengembang hanya memiliki sejumlah penekanan tombol di dalamnya sebelum mereka mati"
CamelBlues

10
Mungkin Anda harus bertanya kepada "banyak orang yang mengeluh" apa alasan mereka.
Eric Lippert

29
@EricLippert, saya percaya P.SE adalah tempat yang sempurna untuk menanyakan sejumlah besar pengembang yang "mengeluh".
Kevin McCormick

Jawaban:


168

Tujuannya adalah pemahaman cepat

"Verbose" berarti "menggunakan terlalu banyak kata". Pertanyaannya adalah apakah "terlalu banyak" itu.

Sekilas kode yang baik harus mudah dipahami. Ini lebih mudah jika sebagian besar karakter langsung melayani tujuan kode .

Sinyal vs Kebisingan

Jika suatu bahasa bertele-tele, lebih banyak kode Anda yang berisik. Bandingkan Java "Hello World" :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... dengan Ruby:

print "Hello World!"

Kebisingan menghabiskan energi mental.

Cryptic vs Clear

Di sisi lain, kepatutan berlebihan dalam bahasa juga menghabiskan energi mental. Bandingkan dua contoh ini dari Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

20
Saya akan mengatakan bahwa yang terakhir adalah tentang keterbacaan di tingkat mikro (di mana kita biasanya lebih suka notasi verbose) di mana sebagai yang pertama adalah tentang keterbacaan di tingkat makro (di mana kita biasanya lebih suka singkatnya)
jk.

67
Untuk program apa pun yang benar - benar melakukan sesuatu Java sering menjadi jauh lebih mudah dibaca, terutama dengan penggunaan perpustakaan yang baik.

9
sebenarnya contoh yang lebih baik dari verbosity skala makro mungkin pola yang bekerja di sekitar fitur bahasa yang hilang
jk.

21
Saya akan mengatakan bahwa contoh dengan Java bukan yang terbaik juga. Hal-hal seperti kebutuhan untuk mendefinisikan kelas dan metode penting dalam kode golf, tetapi hampir tidak dalam aplikasi nyata. Tidak seperti Java yang membutuhkan banyak kode untuk menampilkan beberapa kata, beberapa baris ini diperlukan untuk membuat program, dan itu berbeda.
Malcolm

27
+1 untuk perbedaan antara Signal vs. Noise dan Cryptic vs Clear
Spoike

118

Ini memengaruhi seberapa banyak kode yang dapat Anda lihat dan parsing dalam sekali pandang

x++ daripada set(x,Integeradd(get(x),1))

ps. Ini bukan hanya masalah membaca kode. Pada hari-hari layar 40x25 maka bahasa jenis APL, atau Perl, lebih berguna daripada Cobol atau Fortran untuk jumlah kode yang bisa Anda baca / halaman. Tapi sekarang ini lebih tentang cache internal Anda sendiri - jika sebuah pernyataan memiliki satu operator, otak saya yang sudah tua akan lebih mudah diuraikan daripada satu dengan 3 simbol dan 4 panggilan fungsi.


19
Saya percaya ini adalah alasan utama. Keterbacaan pada ruang terbatas seperti selembar kertas atau monitor.

1
+1, dan sepenuhnya setuju, dan saya kode pada laptop 13 ", tapi sekali lagi situs ini memiliki 3 monitor sebagai logo mereka ... harus agak terkait :)
ZJR

1
@ZJR - lihat edit.
Martin Beckett

3
Jadi apa yang dilakukan setmetode ini di sini? Apakah itu benar-benar mengatur sesuatu (yaitu xparameter pertama ) atau apakah itu mengembalikan sesuatu (yaitu penugasan xsetelah panggilan)? Saya akan mengatakan ada beberapa duplikasi aneh yang terjadi pada contoh verbose.
Jesse C. Slicer

8
Satu hal yang hilang di sini adalah kegunaan ideograf - bahwa simbol bisa lebih bermakna daripada kata-kata. Misal +lebih bermakna daripada plus. =lebih baik daripada equals. Ini tentu saja dapat diambil terlalu jauh (dan telah dilakukan oleh beberapa bahasa) tetapi ketika digunakan dalam jumlah sedang, sangat kuat.
mcmcc

29

Jika verbositas bahasa mengurangi keterbacaan kode, maka itu buruk.

Beberapa bahasa memiliki sintaksis verbose sedemikian rupa sehingga memahami makna kode membutuhkan waktu lebih lama (saya berpikir tentang VB.NET versus C #):

If something Then
End If

if(something)
{}

Itu benar-benar bermuara pada apa yang akrab dan nyaman dengan coder.


6
Saya bekerja di C # kebanyakan, tetapi ketika saya membaca VB saya menemukan saya membacanya seolah-olah itu C #. Saya mengabaikan semua itu If .. Then .. End Ifdan hanya membaca apa yang penting.
Andy Hunt

7
sama seperti Andy. Saya menemukan keduanya sama-sama mudah dibaca. Saya bahkan cenderung mengatakan bahwa saya lebih suka varian VB kecil (walaupun saya lebih terbiasa dengan c #).
dagnelies

9
VB.NET tidak bertele - tele dibandingkan dengan beberapa pelanggar buruk lainnya!

3
@AndyBursh - Persis saya. Saat membaca VB.NET Anda melakukan beberapa terjemahan mental di atas dan di luar pemahaman kode.
Oded

6
Oded, End-If adalah konstruksi yang jauh lebih mudah dipahami untuk akhir pernyataan-if daripada kurung ketika kurung bersarang di dalam pernyataan-if lain, di dalam loop, di dalam loop lain, di dalam fungsi yang ada di dalam kelas. Semua blok yang disebutkan di atas menggunakan tanda kurung yang sama, yang berarti bahwa mencoba mencari tahu mana yang cocok dengan braket akhir kurang intuitif.
Andrew Neely

27

Lihatlah AppleScript , salah satu bahasa yang paling bisa saya pikirkan yang dapat dianggap mutakhir , cobalah untuk menulis sesuatu yang trival di dalamnya dan kembali dan coba dan bantah bahwa verbositas adalah sifat yang baik dalam suatu bahasa.

Mencoba mengingat semua semantik di mana kata kunci pergi dan apa kata kunci itu non-sepele jika Anda tidak melakukannya setiap hari.

Lihat saja semua kebisingan kata kunci dalam contoh sepele ini:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

hal yang sama diberikan bashdengan alat Unix tradisional akan singkat tetapi samar untuk sebagian besar pengguna OSX, sehingga ada keseimbangan yang harus dipukul.


15
Tidakkah Anda ingin return the 0ketika Anda mengetik itu? AppleScript adalah satu-satunya bahasa yang saya tahu yang memungkinkan kata kunci membuat Anda berduka lawan ... Maksud saya rekan kerja.
ccoakley

Applescript IDE, Script Editor, di tahun 90-an, digunakan untuk membantu mengatasi verbositas dengan perekaman applescript tindakan, itu tidak terlalu pintar, tapi agak berguna ketika scripting Finder ... sekitar tahun 1998 rekaman agak pecah dan tidak pernah diperbaiki lagi . (Entah jika transisi OSX memperbaikinya, IIRC, tidak)
ZJR

3
Jawaban OSX untuk ketidaknyamanan AppleScript adalah Automator. Mari kita ganti teks yang mudah diketik dengan perpustakaan raksasa blok fungsi yang dapat diseret, dideskripsikan secara verbal, dan tidak dijelaskan dengan baik!
fluffy

Hal terburuk tentang AppleScript adalah bahwa setiap aplikasi yang ingin Anda kendarai dapat memiliki terminologi yang berbeda. Apple mendefinisikan rangkaian perintah tertentu yang harus didukung oleh semua program, tetapi secara umum, mengetahui cara membuat skrip satu aplikasi hanya bantuan terbatas dalam membuat skrip yang lain.
kindall

1
Applescript sulit untuk ditulis, tetapi mudah dipahami manusia ... dalam batas-batas programmer menempatkan kait applescript dengan sintaks yang dapat dimengerti ke dalam aplikasi yang digerakkan.
aramis

23

Saya pikir Anda perlu mengubah pertanyaan di kepala itu dan bertanya: Mengapa beberapa orang berpikir kode singkat itu baik?

Jawaban saya adalah ada dua alasan dasar:

Alasan Mengapa Terse Bisa Menjadi Lebih Baik

Ini termasuk menjadi lebih mudah dibaca, dengan cara yang sama bahwa kalimat pendek bisa lebih dimengerti daripada kalimat berbunga-bunga dan bertele-tele. Seringkali bahasa pemrograman yang mencoba dan meniru tata bahasa bahasa Inggris akhirnya menjadi sangat bertele-tele, membutuhkan perluasan besar kode untuk melakukan tindakan paling sederhana. Seringkali Anda akan menemukan bahwa semakin banyak suatu bahasa mengemulasi bahasa tertulis maka semakin sulit untuk membujuknya melakukan operasi yang kompleks secara logis.

Alasan Mengapa Terse Bisa Lebih Buruk

Beberapa bahasa (dan saya sedang berpikir tentang Perl) menggunakan array simbol-simbol aneh, yang tampaknya hampir dipilih secara sewenang-wenang, sebagai bagian dari sintaksis mereka. Bagi siapa pun yang tidak terbiasa dengan hieroglif ini maka bahasa menjadi tidak bisa ditembus. Ini juga menjadi mudah untuk membuat kesalahan ketik yang tidak mudah dilihat. Ekspresi reguler barangkali melambangkan keanehan semacam ini.

Juga, beberapa orang suka pamer dengan menulis kode singkat karena, terus terang, mereka pikir itu membuat mereka terlihat pintar. Anda melihat ini kadang-kadang di StackOverflow, di mana orang sering akan mengirimkan jawaban yang sangat kompak dengan mengorbankan keterbacaan. Ini adalah semacam "mengesankan teman-teman Anda" dengan seberapa banyak Anda tahu filosofi, tetapi programmer yang baik menyadari bahwa " golf kode " bukan cara untuk membuat perangkat lunak yang dapat dirawat.


Saya tidak akan mempertimbangkan singkat dari verbose. Verbose membawa konotasi negatif, sehingga kemungkinan akan lebih cocok untuk antonim yang membawa konotasi positif.
Joshua Drake

6
terseadalah antonim dari verbose, tersedapat membawa konotasi negatif yang sama (lihat Perl)

1
@JarrodRoberson: Saya benci menjadi orang yang bertele-tele pada Jumat malam dari semua hal, tetapi saya melihat beberapa tesaurus online dan tidak satupun dari mereka memiliki terseantonim verbose(atau sebaliknya). / bebek
Scott Mitchell


15

@ Terus terang, saya akan menyarankan bahwa salah satu cara untuk melihat masalah verbositas adalah dengan menyadari bahwa pemrograman selalu merupakan campuran dari dua gaya yang agak berbeda dalam menemukan dan mengekspresikan solusi.

Gaya pertama dan lebih verbose adalah pemrograman berorientasi bahasa (linguistik). Gaya ini menggabungkan kata-kata seperti-kata benda dan kata-kata seperti-kata dalam struktur seperti kalimat, dan dimaksudkan untuk dibaca dan dipahami dengan cara yang sama seperti paragraf yang ditulis dengan baik. Pemrograman linguistik adalah gaya pemrograman yang paling universal karena bahasa itu sendiri bersifat universal. Untuk alasan yang sama, dukungan program jangka panjang selalu membutuhkan komponen linguistik yang kuat, karena hal pertama yang akan dicari oleh programmer baru adalah sebagai pemahaman konseptual tentang apa yang sedang dilakukan. Sebagai aturan umum, semakin jauh Anda menjauh dari konteks di mana Anda membuat sebuah program, semakin penting gaya bahasa pemrograman untuk memastikan bahwa asumsi dan konsep Anda tidak akan disalahpahami oleh orang berikutnya yang mencoba memahami kode Anda. .

Gaya kedua dan lebih ringkas adalah pemrograman berorientasi matematika (matematika). Gaya penalaran ini juga bergantung pada bahasa, karena misalnya variabel analog dengan kata benda dan operator dengan kata kerja. Namun, penalaran matematis memanfaatkan kemampuan otak kita yang luar biasa dan sangat paralel untuk melakukan transformasi spasial yang kompleks pada objek yang berada dalam garis pandang kita. Dengan merepresentasikan kata benda dan kata kerja sebagai simbol yang ringkas dan khas yang dapat diatur menjadi objek imajiner yang terstruktur dengan baik - persamaan - kita kemudian dapat menggunakan kemampuan visual yang sangat paralel untuk melakukan rotasi, penggantian, gerakan, inversi, dan transformasi lain pada imajiner ini benda. Hasilnya adalah amplifikasi yang sangat besar dari jumlah kasus yang dapat kita tangani sekaligus, karena setiap simbol dapat mewakili seluruh kelas objek yang terkait erat.

Perhatikan bahwa untuk menerapkan pemrosesan visual secara efektif, Anda perlu menjaga objek imajiner Anda dalam ukuran dan fitur yang sama dengan objek nyata. Jika bidang visi yang dibutuhkan menjadi terlalu luas, atau simbol tidak dapat digunakan seperti tanda bergerak pada objek, atau jika Anda harus "membaca huruf" dan mengubahnya menjadi kata-kata, kemampuan untuk melakukan transformasi kompleks andal akan jatuh cepat bahkan untuk ahli matematika yang sangat baik.

Itulah sebabnya orang-orang yang tenggelam dalam gaya pemrograman matematika dapat benar-benar tidak bahagia jika sebuah persamaan tersebar dan diekspresikan dalam apa yang mereka sebut gaya linguistik “verbose”. Itu bukan karena persamaannya telah berubah secara signifikan, itu karena menyebarkannya seperti itu dapat membuatnya hampir mustahil untuk menerapkan gaya visual pemahaman padanya. Namun pada saat yang sama, seorang programmer baru yang sama sekali tidak akrab dengan simbol-simbol pendek cenderung lebih suka versi yang lebih verbal yang memberikan informasi lebih banyak bahasa untuk awalnya memahami apa yang dilakukan kode.

Jadi apa yang akan saya rekomendasikan?

Gunakan kedua gaya, tetapi perhatikan mengapa Anda menggunakan masing-masing gaya.

Misalnya, segala sesuatu yang memiliki peluang untuk berinteraksi dengan dunia luar harus secara intensif bertele-tele pada tingkat tertentu, bahkan jika hanya dalam bentuk komentar sebaris yang dicampur dengan kode, dan juga harus mencakup pemeriksaan otomatis untuk penggunaan yang benar. Notasi cryptic dan terutama yang tidak lengkap tidak memiliki bisnis dalam antarmuka seperti itu, karena mereka hampir dijamin akan disalahpahami pada beberapa titik. The 1999 hilangnya Mars Climate obiter karena kegagalan untuk mengenali apakah unit perangkat lunak antarmuka yang dinyatakan dalam pound atau Newton adalah contoh yang runcing bahaya mengandalkan terlalu santai di nomor mentah di software atau hardware interface.

Sebaliknya, segala bentuk pemrograman yang sangat algoritmik dan matematis adalah kandidat pemrograman ringkas yang baik yang mendukung gaya penalaran matematis. Jika seseorang yang baru harus mempertahankan kode seperti itu, biasanya akan lebih baik bagi mereka untuk mempelajari notasi matematika daripada mencoba mengubah kode menjadi bentuk yang lebih verbose. Tentu saja harus selalu ada dokumentasi yang mudah tersedia untuk menjelaskan bagian matematika kode yang tersedia untuk pengembang tersebut, tetapi itu adalah masalah terpisah.

Di antara kedua ekstrem ini ada banyak kasus di mana programmer memiliki keleluasaan besar. Saya akan menyarankan melihat bagaimana kode akan dipertahankan dalam jangka panjang, dan mencoba mengakomodasi kebutuhan orang-orang yang paling mungkin mempertahankan kode dalam jangka panjang.


8

Sejumlah orang telah mengisyaratkan sesuatu yang saya pikir mungkin harus dinyatakan secara eksplisit.

Verbositas cenderung mendukung pemahaman pada tingkat mikroskopis - umumnya mengarah pada pernyataan individu yang mudah dibaca dan dipahami. Verbositas juga cenderung mengurangi tingkat keakraban dengan bahasa yang diperlukan untuk memahaminya (setidaknya sampai tingkat tertentu). Bahasa yang paling bertele-tele (misalnya, COBOL) dapat setidaknya terbaca bahkan oleh non-programmer lengkap.

Kecenderungan cenderung ke arah yang berlawanan: itu membantu pemahaman pada tingkat makroskopik, terutama oleh programmer dengan keakraban paling akrab dengan bahasa tertentu. Pada saat yang sama, kurangnya keakraban dengan bahasa tertentu dapat mencegah bahkan pemahaman yang belum sempurna, bahkan dari programmer yang sebaliknya cukup berpengalaman.

Dengan demikian, keterbacaan sangat bervariasi tergantung pada audiens target. Di satu sisi, pertimbangkan proyek besar dan kompleks yang ditulis dan dikelola oleh orang-orang yang bekerja hampir secara eksklusif pada proyek itu, yang sebagian besar memiliki latar belakang pemrograman dan pendidikan yang substansial (misalnya, banyak PhD). Ini akan cenderung mendukung bahasa yang lebih ringkas.

Pada titik yang berlawanan, pertimbangkan sebuah proyek yang jauh lebih sederhana (walaupun mungkin masih cukup besar) yang dikelola terutama oleh orang-orang yang benar-benar mengkhususkan diri dalam bisnis yang terkait dengan perangkat lunak, daripada dalam perangkat lunak itu sendiri. Ini hampir pasti akan mendukung bahasa yang jauh lebih verbal.


6

Daripada pergi ke buku teknis, saya kembali ke Elements of Style * oleh Strunk and White. Konsep yang mendasarinya adalah "Tepat" dan "Jangan katakan lebih dari yang dibutuhkan." Yang lainnya adalah komentar.

Diterapkan untuk pemrograman, ini tentang menjadi sangat tepat, tetapi tidak memiliki bulu yang tidak dibutuhkan. Fluff ekstra bisa berupa sintaks, tetapi bisa juga lebih banyak kata daripada yang dibutuhkan untuk menyampaikan makna. (Tentu saja tidak terlalu sedikit untuk memungkinkan ambiguitas)

  • Saya mengutip versi aslinya karena ini adalah versi yang paling ringkas. :-)

5

Pada akhirnya, apa pun yang 'berbeda' akan menyebabkan orang melolong. Saya nyaman dengan sintaks gaya C dan karenanya ok dengan bahasa lain yang memiliki sintaksis yang sama (C ++, Java, C #). Jadi saya cenderung menyukai gaya khusus ini.

Bahasa cenderung menemukan keseimbangan antara cukup deskriptif, dan tidak bertele-tele.

Perl adalah contoh di mana Anda dapat menulis kode yang sangat ringkas. Bagi yang belum tahu, kode yang ditulis oleh Ninja Perl bukanlah keajaiban.

COBOL adalah contoh dari terlalu bertele-tele.


5
Bagaimana ini menjawab pertanyaan?
ChrisF

verbositas berbeda untuk semua orang. Itulah maksud komentar saya. Jika Anda berada di kamp C / C ++, verbositas yang diterima berbeda dari jika Anda berada di kamp perl.
Nasir

kode yang ditulis oleh seorang ninja perl adalah keajaiban? Serius, saya pikir ini mimpi buruk.
Kevin

saya menghindari perl :)
Nasir

Untuk programmer COBOL mungkin terlalu bertele-tele dibandingkan dengan bahasa lain. Namun, COBOL yang ditulis dengan baik bisa mudah dibaca oleh klien bisnis. Ini memungkinkan mereka untuk memverifikasi kode melakukan apa yang mereka butuhkan dengan membacanya.
BillThor

4

Saya pernah membaca di suatu tempat bahwa banyak debat verbal datang dari programmer baru vs tangan lama. Analogi yang digunakan adalah ketika kita mempelajari sesuatu yang baru, kita memberi tahu diri kita sendiri sebuah "cerita" untuk melewatinya (pikirkan ketika Anda belajar aljabar di HS). Ketika kami memperoleh pengalaman, kami bergerak melampaui kebutuhan akan cerita yang menjelaskan komponen-komponen individual dan kami memahami jumlah yang lebih besar. Kode kami menjadi lebih padat dan lebih singkat, dengan komentar hanya menjelaskan item yang diperlukan, alih-alih mengulangi apa yang dikatakan kode.

Saya menemukan ini benar antara saya dan seorang rekan kerja. Dia menulis kode dengan banyak komentar yang menjelaskan apa baris kode itu, dan banyak ruang putih. Jika saya membacanya, saya menemukan bahwa saya hanya dapat memasukkan beberapa baris kode pada satu layar karena ini. Itu membuat memahami setiap baris individu jauh lebih mudah, tetapi menggosok seluruh fungsi menjadi jauh lebih sulit.

Saya cenderung menulis kode tanpa spasi atau komentar ekstra. Ini membuat melihat keseluruhan jauh lebih mudah, tetapi Anda harus bisa "mendapatkan" kode "kata-kata" masing-masing. Jika Anda mencoba membaca jawaban ini dengan setiap kata berada di barisnya sendiri, dengan banyak spasi putih / komentar / kata-kata ekstra maka akan jauh lebih mudah untuk memahami setiap kata, tetapi jauh lebih sulit untuk memahami keseluruhan.


Tidak ada yang menentang komentar. Masalahnya adalah bahasa seperti java, applescript, atau Visual Basic, yang memiliki banyak elemen redundan tetapi wajib.
Marcin

2
@ Marsin saya tidak menentang komentar juga, tetapi ketika mereka seperti ini: i++; //this is adding one to var iitu berlebihan.
Spencer Rathbun

Pertanyaannya adalah tentang bahasa pemrograman.
Brendan Long

2
@ BrendanLong Hmm, mungkin saya tidak jelas. Saya menyamakan komentar yang tidak perlu dengan bahasa pemrograman verbose. Banyak kata untuk mengatakan hal yang sama, hanya bahasa pemrograman verbose yang membutuhkannya setiap saat.
Spencer Rathbun

Dapat dikatakan bahwa suatu fungsi tidak boleh terdiri dari lebih dari beberapa baris saja. Jika sulit untuk memahami bagaimana fungsi ini bekerja, itu mungkin bukan karena terlalu banyak komentar. Tapi saya setuju bahwa komentar yang hanya mengatakan apa yang sudah jelas harus dihindari.
leftaroundtentang

4

Einstein benar: "Jadikan sesederhana mungkin, tetapi tidak sederhana."

Ini juga berlaku untuk kode. Jika Anda dapat menyederhanakan kode dengan menghapus elemen berulang dan tidak perlu, itu adalah hal yang baik.

Juga, beberapa studi kasus menunjukkan bahwa produktivitas pemrogram diukur dalam garis kode lebih atau kurang konstan. Begitu juga jumlah bug per LOC. Jadi beralih ke bahasa yang memungkinkan Anda melakukan lebih banyak per baris kode dapat dianggap sebagai peningkatan produktivitas, jika semua hal lainnya tetap sama.

Yang sedang berkata, ada kecenderungan dalam industri ini untuk lebih dari insinyur dan memperumit apa yang seharusnya menjadi hal-hal sederhana. Hal-hal sederhana seperti memasukkan rincian kontak dalam basis data relasional. Saya telah melihat beberapa solusi yang sangat rumit dan salah arah ( batuk MDA) untuk masalah khusus itu. Bahasa seperti Scala dan Ruby adalah contoh yang baik dari alat yang kuat yang di tangan orang-orang tertentu menghasilkan kode yang tidak dapat dipahami, terlalu rumit, dan tidak bisa dirawat dengan baik. Hanya karena Anda dapat menggunakan beberapa tingkat tipuan dengan beberapa goresan kunci tidak berarti Anda harus mengacaukan setiap kuku yang terlihat dengan palu tertentu.

Ketika digunakan dengan benar, Anda mendapatkan kode bersih yang bagus yang pendek dan mudah dimengerti. Bila digunakan dengan buruk, Anda lebih baik membatasi individu yang bersangkutan untuk menggunakan visual basic atau bahasa yang serupa untuk mencegah kerusakan lebih lanjut.

Keahlian sejati terletak pada membuat hal-hal rumit dengan cara yang sederhana, bukan dalam membuat hal-hal sederhana dengan cara yang rumit.


3

Sesuatu yang tidak dipukul orang lain adalah jumlah kode yang dapat Anda muat dalam satu layar. Ini membantu karena beberapa alasan:

  • Lebih sedikit menggulir bolak-balik saat Anda mengerjakan (atau membaca) beberapa fungsi dalam satu file.
  • Pengguliran horizontal kurang (berhenti membaca, klik dan seret bilah gulir, berhenti membaca, klik dan seret bilah gulir ...).
  • Pemindaian lebih cepat, karena ada sintaks yang kurang berguna menghalangi cara menemukan apa yang Anda inginkan.

benar-benar berapa banyak pengguliran yang dilakukan pada layar 1920 X 1080 dengan ukuran font yang cukup mudah dibaca? Ada juga hal-hal ini yang disebut pintasan keyboard untuk navigasi.

@JarrodRoberson - Layar saya menunjukkan sekitar 30 baris. Jika saya membuat jendela kode layar penuh dan menurunkan ukuran font menjadi hampir tidak dapat dibaca, saya mendapatkan 60 baris. Saya harus mengerjakan beberapa ribu file baris (bukan karena pilihan, saya jamin). Saya memang menggunakan "navigator" di IDE saya, tetapi masih jauh dari nyaman seperti melirik dua bagian kode yang sama-sama ada di layar.
Brendan Long

Tidakkah IDE Anda mendukung tampilan terpisah?
leftaroundabout

2
Anda berdua kehilangan intinya - apakah IDE saya dapat membuat scroll lebih buruk , tidak akan sebagus tidak harus menggulir (atau menggunakan hotkey, atau splitscreen) sama sekali . Ini seperti mengatakan "Di layar keyboard baik-baik saja, tidak pernahkah Anda mendengar tentang mengklik sesuatu?"; Jelas saya miliki, tetapi tidak mengalahkan memiliki keyboard sungguhan.
Brendan Long

Samar-samar saya ingat bahwa sebenarnya ada penelitian yang menunjukkan ini benar (terutama bagian bergulir). Harus menggulir untuk melihat keseluruhan unit logis membuatnya lebih sulit untuk dipahami. Kedengarannya masuk akal, setidaknya.
Konrad Rudolph

1

Karena lebih banyak kode berarti lebih banyak waktu pengembangan dan lebih banyak bug.

Jika Anda menulis 100 baris kode, bukan 300 baris kode. Itu berarti hampir 1/3 waktu pengembangan yang Anda butuhkan dan 1/3 potensi bug yang mungkin Anda temui.

Dalam sebagian besar keadaan Anda perlu menyeimbangkan efisiensi dan keringkasan, karena menulis lebih sedikit kode berarti mesin perlu melakukan lebih banyak hal dan itu akan mengurangi efisiensi.


2
Saya berharap bug yang jauh lebih tersembunyi di 100 garis khas Perl daripada di 300 baris Ada. - Mengenai "karena menulis lebih sedikit kode berarti mesin perlu melakukan lebih banyak hal dan itu akan mengurangi efisiensi", mungkin ada korelasi seperti itu tetapi itu bukan hubungan sebab akibat. Hanya saja bahasa dinamis yang singkat dan / atau ditafsirkan seperti Ruby, Perl dan Python cenderung lebih lambat daripada bahasa yang dikompilasi statis lebih verbose seperti C atau Fortran. Tetapi beberapa program Haskell, Python w / PyPy atau C ++ yang dikompilasi mungkin jauh lebih cepat daripada verbose misalnya ditafsirkan Dasar, Groovy, Smalltalk, atau bahkan kode C #.
leftaroundabout

1

Biasanya, orang menyukai bahasa yang mudah dibaca / verbose daripada yang samar / singkat. Namun, saya pikir sebagian besar orang berasimilasi "verbositas" dengan "kekacauan", yang bukan hal yang sama.

Misalnya: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

adalah pernyataan yang sangat singkat. Ini berisi semua yang ingin Anda ketahui. Namun, karena kesempitan itu, sulit dimengerti. Di sisi lain, versi yang sedikit lebih verbose dari program yang sama akan cukup mudah dipahami karena lebih mudah dibaca. Ini tentu saja bukan properti dari bahasa itu sendiri, tetapi beberapa bahasa cenderung lebih verbositas sementara yang lain cenderung lebih ringkas dalam cara pemrograman mereka.

Yang paling ekstrem, adalah http://en.wikipedia.org/wiki/Literate_programming , yang saya anggap sebagai konsep yang cukup menarik.

Satu aspek lain adalah "verbosity yang tidak diinginkan", juga disebut "clutter". Hal-hal yang harus Anda tambahkan karena alasan teknis, kurang gula sintaksis, API kembung, dan sebagainya.

Saya pikir sintaks yang jelas dan intuitif sangat penting. Itu juga harus cukup verbal untuk memudahkan pembacaan yang mudah. Pernyataan yang terlalu pendek yang dikemas dengan terlalu banyak logika seringkali dapat menyebabkan lebih banyak waktu untuk mendekripsi daripada rekan-rekan mereka yang sedikit lebih panjang. Di sisi lain, kode kembung yang tidak berguna yang penuh dengan garis boilerplate untuk melakukan sesuatu yang benar-benar sederhana juga merupakan gangguan.


4
Anda mungkin ingin memeriksa ulang [arti dari ringkas] ( en.wiktionary.org/wiki/concise ), karena hampir merupakan antonim dari cryptic. Apakah Anda mungkin kode di Jawa?
Joshua Drake

2
Saya lebih suka kode verbose ditulis dalam bahasa ringkas.
Brendan Long

@ Yosua: ya, saya perhatikan bahwa itu bisa ditafsirkan dengan cara yang sangat berbeda, jadi saya mengedit jawaban saya. ... dan apa hubungannya java dengan itu?
dagnelies

1
Komentar untuk menyatakan mengapa downvote mungkin lebih menarik daripada downvote itu sendiri.
dagnelies

@arnaud salahku karena menggunakan wiktionary. Pencarian google define: Ringkas dimulai: "Memberikan banyak informasi dengan jelas" yang kode sampel Anda jelas-jelas dilanggar. Meskipun saya harus mengakui implikasi asli singkat, jelas dan ringkas sekarang bepergian ke sana.
Joshua Drake

1

Verbosity menjadi kecenderungan untuk menggunakan teks dalam jumlah yang luas, dan Terseness menggunakan teks yang sangat sedikit ...

Verbositas buruk karena:

  1. itu memperkenalkan lebih banyak peluang untuk kesalahan ketik
  2. itu membuatnya lebih sulit untuk membaca kode di layar atau kertas, dan / atau memasukkan pada kartu punch
    1. ini meningkatkan waktu debug
    2. ini membuat pemahaman kode untuk peningkatan / pemeliharaan lebih sulit
    3. ini dapat menyebabkan duplikasi kode yang tidak diinginkan
  3. itu agak meningkatkan kemungkinan kesalahan sintaksis
  4. itu mengurangi fleksibilitas pengkodean, dalam hal itu, sebagian besar bahasa verbose sangat terstruktur dan tidak memiliki banyak cara untuk mengatakan hal yang sama.
  5. ini meningkatkan waktu pengkodean dan kompilasi
  6. dapat mengambil lebih banyak ruang penyimpanan.

Tingkat verbositas tertentu sangat penting untuk kejelasan, namun ...

tingkat Verbositas minimal baik karena:

  1. lebih mudah bagi manusia untuk membaca dan melampirkan nilai semantik daripada kode simbolik murni
  2. Dalam penamaan variabel dan fungsi, membuatnya lebih mudah untuk debug, port, dan memelihara kode
  3. dalam operasi bahasa tingkat dasar dan kata kunci dari bahasa yang kompleks, itu mengarah ke lebih sedikit penugasan operasi / kata kunci yang salah.

Beberapa contoh yang indah dari perintah terlalu singkat bagi banyak orang termasuk standbys BASIC lama val(x$), str$(x)dan chr$(x)... kembali nomor dari representasi string nya, kembali string untuk nomor, dan kembali satu karakter yang memiliki nilai ascii x sebagai string.

Atau pointer C / C ++ dan oleh operator referensi &dan *versus byrefkata kunci BASIC . Dalam C / C ++, saya dapat memiliki variabel X, dan melewatkan pointer ke variabel itu, tetapi saya harus mengingat yang mana adalah pointer dan yang merupakan "gunakan pointer sebagai variabel yang ditunjuknya"; pada dasarnya, saya cukup meneruskan referensi dengan kata kunci byref di panggilan fungsi, yang lebih jelas, tetapi kurang fleksibel:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

Dalam kode ini, konten x bisa dimodifikasi karena bendera byref. Beberapa rasa memungkinkan byref di panggilan, yang lain dalam definisi, beberapa di keduanya.

Verbositas penting bagi programmer kasual untuk dapat menggunakan simbolisme dengan lebih mudah; BASIC atau python lebih mudah dibaca manusia dan lebih bertele-tele daripada C / C ++, dan karenanya jauh lebih berguna untuk programmer biasa; kesederhanaan C / C ++ membuatnya jauh lebih baik untuk programmer yang lebih berpengalaman, yang perlu melihat lebih banyak kode dan kode yang lebih kompleks pada satu layar penuh, tetapi harus mempelajari berbagai konvensi struktur simbolik. Pada akhirnya adalah APL, yang hampir sepenuhnya tidak dapat dibaca manusia.

Masalah yang terkait erat adalah kode kejelasan yang sering tidak jelas, dan kode yang terlalu bertele-tele (seperti dalam AppleScript) bisa sama tidak jelasnya. Keakraban dengan bahasa yang diberikan meningkatkan kejelasan kode singkat dalam bahasa tersebut - pemula yang mentah, menghadapi kode C ++ cenderung hanya dapat menguraikan rumus, dan bahkan banyak BASIC atau kode Python yang fungsional terlalu singkat untuk dipahami, tetapi applescript dapat menjadi bingung, umumnya, tanpa bantuan kamus bahasa. Yang paling jelas saya temui tanpa kebingungan yang disengaja adalah Inform 7 ...

Di masa lalu

Pertimbangan penting lainnya di masa lalu, tetapi yang tidak lagi penting bagi pembuat kode hobi, adalah ruang operasi dan penyimpanan. (Ini masih penting di kelas atas.) Ingatlah bahwa banyak bahasa diinterpretasikan, terutama rasa BASIC, dan banyak lagi yang dikompilasi run-time, ruang kode penting, terutama ketika disk hanya menampung 128KiB, dan kartu punch individu hanya 80B.

Ada beberapa solusi - tokenisasi sangat umum di BASIC; kata kunci bahasa individu dikurangi menjadi 1 atau 2 kata byte baik di atas 128 atau ruang karakter kontrol. Tokenisasi juga mengarah ke kompilasi bytecode (seperti pada Inform and the Z-Machine).

Kompilasi dan menghubungkan banyak file objek juga digunakan untuk mengatasi keterbatasan ruang. Bagian kode Pascal 100KiB hanya dapat dikompilasi menjadi 5KiB; dengan menautkan banyak file yang dikompilasi, seseorang dapat membangun aplikasi besar tanpa memiliki akses ke drive format besar (mengingat bahwa 10MiB luar biasa besar, dan membeli mobil baru yang mahal).

Namun, semakin banyak bahasa, semakin banyak kode yang dimasukkan ke dalam potongan disk dan ram, dan dengan demikian mengkompilasi potongan yang lebih besar sekaligus. Perlu diingat: "minicomputer" pada awal 1970-an mungkin hanya memiliki 64KiB ram (Honeywell 800 memiliki instalasi dasar 4 bank masing-masing 2048 kata masing-masing 8B). APL dan bahasa simbolik serupa mendekati 1B per instruksi ditambah operandnya, dibandingkan 3B-10B jauh lebih besar per instruksi plus operan. (Itu adalah mimpi buruk untuk mengetikkan kartu punch, terutama karena simbol pada dasarnya adalah font pada tipe-bola, dan banyak cardpunches tidak memiliki simbol pada tombol ...)

Juga, perlu diingat bahwa kartu tidak dapat dihapus ... dan banyak program dimasukkan pada kartu. Meskipun tidak mahal secara individual, kode Anda yang lebih terkompresi dapat berada di kartu, semakin sedikit yang Anda butuhkan, dan semakin besar programnya, atau semakin murah. Ini adalah bagian dari alasan BASIC memiliki rangkaian beberapa instruksi per baris dalam berbagai rasa - ini diperkenalkan untuk menghemat kartu punch. (Atau begitulah kata teks pemrograman Vax Basic saya.) Walaupun saya belum memprogram untuk pembaca kartu, saya sudah melakukan kartu meninju untuk Honeywell 800 dalam FORTRAN, BASIC, APL, dan beberapa bahasa simbolis lainnya.


Verbositas dalam banyak kasus meningkatkan kemungkinan kesalahan tipografi terdeteksi pada waktu kompilasi daripada hanya menghasilkan perilaku yang salah.
supercat

-1

Seperti halnya banyak hal, jawabannya tergantung pada definisi konkret dari "verbosity". Jika definisinya sedemikian rupa sehingga verbositas menyiratkan redundansi maka saya berpendapat itu selalu buruk. Perhatikan bahwa dengan definisi seperti itu, program Java hello world yang sering dikutip tidak akan memenuhi syarat sebagai "verbose", karena tidak ada di dalamnya yang berlebihan.


1
Kurung seimbang dan titik koma adalah redundan, karena sebagian besar adalah deklarasi tipe.
Marcin

1
@ Marsin: Ya, tetapi mereka membuat menulis pengurai / penganalisa untuk bahasa lebih mudah. Saya cukup yakin bahwa sintaks semacam itu ada untuk kepentingan pelaksana bahasa, bukan programmer yang menggunakan bahasa.
ccoakley

1
@Marcin - sepenuhnya bergantung pada bahasa apakah jenis deklarasi diperlukan atau tidak. Sistem tipe tertentu sama sekali tidak dapat diputuskan, karenanya .... mengenai tanda kurung dan titik koma, yah, Anda lebih suka bahasa dengan tata bahasa yang jelas dan tampilan yang pendek - atau menyusun bahkan program kecil bisa memakan waktu berjam - jam dan pada akhirnya Anda Anda harus memilih interpretasi program mana yang Anda inginkan.
Ingo

1
@ingo Saya tidak mengetahui bahasa apa pun di mana semua variabel atau fungsi harus memiliki deklarasi tipe karena kompleksitas sistem tipe. Bahkan, saya akan mengatakan bahwa bahasa dengan sistem tipe yang lebih kuat lebih memungkinkan untuk deklarasi seperti itu dihilangkan.
Marcin

1
@Marcin, tidak ada alasan untuk marah. Anda bilang saya akan mengatakan bahwa bahasa dengan sistem tipe yang lebih kuat lebih mungkin untuk membiarkan deklarasi seperti itu dihilangkan dan saya memberi Anda sebuah contoh, di mana sistem tipe yang lebih kuat membutuhkan lebih banyak anotasi jenis. Jika Anda merasa itu tidak bertentangan dengan penampilan Anda, maka baiklah, jadi itu saja.
Ingo

-1

Programmer cenderung menyukai bahasa dengan kekuatan ekspresif karena memungkinkan mereka untuk membuat kode hal-hal sederhana, yang sering harus sering dilakukan, dalam potongan kode kecil. Bahasa lisan cenderung berarti bahwa banyak, banyak baris kode harus digunakan untuk melakukan hal yang sama berulang kali. Namun, mungkin ada sesuatu yang harus dibayar dengan bahasa ekspresif karena mereka mungkin tidak secepat mengeksekusi sebagai bahasa tingkat tinggi yang lebih sederhana. Jika saya bisa memberikan contoh dalam kontras antara C dan C ++. C ++ memberikan kekuatan yang lebih ekspresif kepada penulis kode - mereka dapat merangkum gagasan objek dunia nyata di kelas. Pemrogram C dapat mencapai hal yang sama tetapi mereka memang memiliki kekuatan ekspresif dari konstruk kelas untuk membantu mereka - sehingga seringkali mereka harus menulis kode yang lebih panjang, lebih rumit (untuk memahami). Tetapi kode itu mungkin berjalan lebih cepat (meskipun ini sangat tergantung pada kualitas kompiler dan sebagainya) karena tidak menggunakan "keterlambatan mengikat" C ++ (yaitu run time refactoring) untuk mengeksekusi kode. C hanya mengeksekusi kode yang dikompilasi dan ditautkan, C ++ harus membuat keputusan (dalam keadaan tertentu) pada saat run time tentang potongan kode mana yang akan dieksekusi.


Dengan "keterlambatan mengikat" ini, Anda mungkin menyebut panggilan fungsi virtual. Tapi itu hanya satu cara di antara banyak cara lain untuk mencapai penggunaan kembali kode. Pengetikan dinamis adalah hal lain, dan kemungkinan akan menjadi contoh yang lebih baik untuk poin Anda karena cenderung memiliki overhead yang lebih banyak daripada panggilan virtual C ++. Tetapi ada juga mekanisme yang tidak mempengaruhi kinerja runtime sama sekali karena mereka dapat sepenuhnya diselesaikan pada waktu kompilasi: dalam bahasa berorientasi objek modern Anda memiliki template / generik, dalam bahasa fungsional statis polimorfisme parametrik.
leftaroundabout

Mengikat terlambat adalah apa yang digunakan untuk membuat panggilan fungsi virtual berfungsi, jadi tidak, saya tidak "maksud panggilan virtual", maksud saya mengikat terlambat. Panggilan virtual adalah bagian dari definisi bahasa, pengikatan akhir inilah yang membuat bagian itu berfungsi. Dan, ya, tentu saja ada contoh lain dalam bahasa lain, saya menawarkan contoh potensi pertukaran antara kekuatan ekspresif dan kecepatan, tidak merekomendasikan satu bahasa ke bahasa lain.
adrianmcmenamin

-1

Saya percaya bahwa ada jawaban untuk pertanyaan yang berakar pada masalah yang lebih mendasar dan teoritis daripada readibility dan jawaban ini terkait dengan teori informasi algoritmik yang didirikan oleh Gregory Chaitin: http://en.wikipedia.org/wiki/Algorithmic_information_theory . Dinyatakan dalam beberapa kata, "isi informasi dari suatu string setara dengan panjang dari representasi string itu sendiri yang terpendek dan terpendek", Ini menyiratkan bahwa program terpendek (yaitu dalam hal panjang leksikografinya) menyelesaikan masalah yang diberikan dengan cermat cocok dengan kompleksitas intrinsik dari masalah yang memberikan solusi dan, oleh karena itu, lebih tergantung pada sifat masalah dan lebih sedikit pada representasi masalah.

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.