Apakah ada studi ilmiah yang ketat tentang prinsip-prinsip gaya pengkodean? [Tutup]


25

Apakah prinsip gaya pengkodean - misalnya, prinsip keluar tunggal - benar-benar hal yang baik? Selalu, atau kadang-kadang saja? Seberapa besar bedanya?

Apa pun pendapat Anda, ini jelas pertanyaan subyektif. Atau apakah mereka?

Adakah yang mencoba melakukan penelitian yang obyektif dan ilmiah tentang prinsip-prinsip gaya pengkodean?

Saya tidak bisa membayangkan bagaimana orang akan melakukan studi double-blind tentang keterbacaan, tetapi mungkin double-ignorant mungkin dilakukan - gunakan siswa yang tidak tahu tentang prinsip yang dipelajari sebagai subjek, dan non-programmer untuk mengelola penelitian.


5
Anda mungkin tertarik membaca kode lengkap. Segalanya tidak bisa diterima, tetapi banyak, dan Anda akan menemukan ikhtisar yang baik dengan data mentah atau sumber dalam buku ini.
deadalnix

Ini juga sangat tergantung pada bahasa, beberapa prinsip berlaku untuk bahasa tertentu dan bukan yang lain. Misalnya single-exit principletidak benar-benar berlaku untuk C ++ karena RAII
Martin York


@Loki - Saya harus memikirkannya, dan saya tidak yakin saya setuju. Memang benar bahwa RAII dirancang sebagian besar untuk mengatasi pengecualian, yang merupakan titik keluar alternatif, tetapi (setidaknya untuk beberapa orang) mereka dihitung sebagai titik keluar alternatif alternatif - tidak benar-benar mengandalkan prinsip keluar tunggal dalam cara itu break, gotoatau returnmelakukan. TKI satu pintu keluar tidak mutlak dalam C ++, tapi itu cukup banyak pandangan saya tentang itu dalam C dan sebagian besar bahasa lainnya. Tapi itu masih relevan dalam arti tidak ketat.
Steve314

1
@ Steve314, artikel ini setidaknya relevan untuk hal yang jauh - artikel ini menguraikan desain untuk metodologi eksperimen semacam itu, yang cukup penting karena kurangnya bukti eksperimental yang tercatat dengan baik di bidang ini.
SK-logic

Jawaban:


11

Saya menggemakan komentar deadalnix: baca Kode Lengkap 2 . Penulis (Steve McConnell) membahas gaya pengkodean secara mendalam dan seringkali referensi makalah dan data.


Ikhtisar mendasar dan disajikan dengan baik tentang pengembangan perangkat lunak profesional, berharap suatu hari saya akan menemukan yang serupa untuk jaminan kualitas. Bab tentang Pemrograman Defensif dan Pemrograman Pseudocode sangat membantu saya. Bab tentang Praktik Pengembangan Kolaboratif tampaknya paling menarik dari semua yang saya baca tentang masalah ini sejauh ini.
nyamuk

Saya belum membaca buku ini, dan mungkin harus, tetapi - berdasarkan komentar dalam jawaban agas - apakah makalah yang dirujuk benar-benar ilmiah dan keras dan objektif? Jika jawabannya "sebanyak mungkin", kompromi apa yang diperlukan? Seperti yang saya sarankan dalam pertanyaan, apakah perlu mengganti double-blind dengan standar yang lebih lemah?
Steve314

@ Steve314: Saya tidak tahu, saya belum memeriksa sumbernya! Tetapi Anda tidak selalu membutuhkan ketelitian ilmiah untuk membangun praktik terbaik. Diskusi tentang pro dan kontra terkadang cukup.
M. Dudley

@emddudley - sepenuhnya benar, tetapi tidak benar-benar tentang pertanyaan ini.
Steve314

@ Steve314: Kode Lengkap akan menjadi titik awal yang bagus untuk Anda, dan saya yakin bahwa beberapa rujukannya membahas masalah analisis ilmiah gaya pengkodean.
M. Dudley

12

Saya sangat meragukan kemungkinan studi tentang subjek yang menghasilkan hasil yang objektif dan saya akan tetap skeptis sampai saya ditunjukkan beberapa penelitian yang meyakinkan.

Programmer yang telah menghabiskan waktu bertahun-tahun membaca dan menulis kode yang mengikuti gaya pengkodean tertentu jelas akan merasa lebih mudah dibaca daripada gaya pengkodean sempurna yang akan mereka lihat untuk pertama kali dalam hidup mereka.

Ini persis sama dengan tata letak pengetikan QWERTY yang paling umum - mudah untuk membuktikan bahwa itu cukup suboptimal dalam hal ergonomi (apakah Anda berpikir bahwa semua karakter kata TYPEWRITER diletakkan di baris paling atas dengan mempertimbangkan kenyamanan harian kita?) .

Tetapi alternatif yang lebih baik seperti Dvorak atau Colemak tidak pernah populer dan tidak mungkin. Dan karena itu orang tidak lebih produktif dengan mereka - fakta. Bahkan jika mereka unggul dalam beberapa pengertian abstrak.

Juga, akan sulit untuk menemukan subjek tanpa paparan sebelumnya untuk pemrograman (karena ini akan mencemari hasil penelitian kami), TAPI bakat untuk pemrograman, DAN keinginan untuk berpartisipasi dalam studi untuk jangka waktu yang cukup lama untuk menunjukkan keduanya singkat Manfaat waktu dan manfaat jangka panjang sehingga mereka dapat dibandingkan satu sama lain ... (Saya tidak tahu apakah mereka saling eksklusif, tetapi para peneliti tidak bisa hanya berasumsi bahwa mereka tidak pernah sama sekali).


1
Keren, saya belum pernah mendengar tentang Colemak sebelumnya
CaffGeek

1
@Chad bahkan kurang dikenal adalah Carpal X, yang saya mainkan untuk sementara waktu. Saya menemukan itu lebih baik daripada Colemak (saya mencapai 90-100 wpm dengan karpalx). Bahkan jika Anda tidak berniat beralih ke tata letak yang eksotis, situs web carpalx membuat bacaan yang sangat menarik tentang mengevaluasi dan mengoptimalkan tata letak keyboard, dan memanfaatkan algoritma genetika untuk kategori masalah ini. Lihat mkweb.bcgsc.ca/carpalx
Konrad Morawski

1
Kadang-kadang manfaat marjinal dari pendekatan alternatif akan cukup besar untuk membenarkan biaya untuk mengadopsi itu; kalau tidak kita semua akan tetap menjadi assembler dan fortran pemrograman Jawaban ini tidak benar-benar menjawab pertanyaan awal apakah ada manfaat marginal atau tidak. Dalam contoh Dvorak, pasti ada dan sudah terbukti, tetapi mereka tidak cukup manfaat untuk membenarkan belajar Dvorak.
Jeremy

@ Jeremy "jawaban ini tidak benar-benar menanggapi pertanyaan awal apakah ada manfaat marginal atau tidak" - OP tidak secara langsung meminta temuan studi tersebut, ia bertanya apakah ada yang mencoba melakukan studi seperti itu, yang lebih membuka pertanyaan. Saya menjawab dengan menunjukkan beberapa alasan logis tentang mengapa itu akan sulit secara teknis, dan mengapa setiap hasil dari studi semacam itu mungkin akan terkontaminasi secara signifikan oleh kebisingan statistik. Jadi, jika jawaban saya dianggap tidak berguna dengan alasan yang Anda berikan, saya pikir saya diturunkan secara tidak adil.
Konrad Morawski

1
@Jeremy inti dari biaya adopsi ini adalah bahwa orang berkinerja lebih baik dengan alat yang lebih rendah asalkan mereka lebih banyak berlatih dengannya. Dan inilah yang akan muncul dalam penelitian yang mencoba untuk memeriksa seberapa baik subyeknya mengatasi gaya pengkodean yang berbeda. Kebisingan yang disebabkan oleh keakraban / ketidaktahuan sebelumnya dengan gaya pengkodean yang Anda ingin mereka gunakan akan mengurangi dampak dari kualitas bawaan dari gaya ini. Kecuali Anda menaikkan level taman bermain dengan mengambil pemula yang lengkap. Tetapi ini menimbulkan kesulitan praktis, seperti yang saya tunjukkan di paragraf terakhir dari jawaban saya.
Konrad Morawski

4

Jawabannya adalah TIDAK! Apakah `break` dan` continue` praktik pemrograman yang buruk? adalah bagian dari pertanyaan ini, jadi saya akan mulai dengan jawaban yang hampir tidak dimodifikasi untuk itu ...

Anda dapat [kembali] menulis program tanpa pernyataan break (atau kembali dari tengah loop, yang melakukan hal yang sama). Tetapi dengan melakukan itu Anda mungkin harus memperkenalkan variabel tambahan dan / atau duplikasi kode yang keduanya membuat program lebih sulit untuk dipahami. Pascal (bahasa pemrograman akhir 1960-an) sangat buruk terutama untuk programmer pemula karena alasan itu.

Ada hasil ilmu komputer yang disebut hirarki struktur kontrol Kosaraju, yang dimulai pada tahun 1973 dan yang disebutkan dalam makalah Knuth (lebih) pemrograman terstruktur terkenal dengan pernyataan dari 1974. Apa yang dibuktikan oleh S. Rao Kosaraju pada tahun 1973 adalah bahwa itu tidak mungkin untuk menulis ulang semua program yang memiliki multi level level kedalaman n ke dalam program-program dengan kedalaman break kurang dari n tanpa memperkenalkan variabel tambahan. Tetapi katakanlah itu hanya hasil teoretis semata. (Cukup tambahkan beberapa variabel tambahan ?! Tentunya Anda dapat melakukan itu untuk merasa bergabung dengan pengguna 3K + di stackexchange ...)

Apa yang jauh lebih penting dari perspektif rekayasa perangkat lunak adalah makalah yang lebih baru, tahun 1995 oleh Eric S. Roberts berjudul Loop Exits and Structured Programming: Membuka Kembali Debat (doi: 10.1145 / 199688.199815). Roberts merangkum beberapa studi empiris yang dilakukan oleh orang lain sebelum dia. Sebagai contoh, ketika sekelompok siswa tipe CS101 diminta untuk menulis kode untuk fungsi yang mengimplementasikan pencarian sekuensial dalam array, penulis penelitian mengatakan hal berikut tentang siswa yang menggunakan istirahat / kembali untuk keluar dari dari sekuensial lingkaran pencarian tepat ketika elemen ditemukan:

Saya belum menemukan satu orang yang mencoba program menggunakan [gaya ini] yang menghasilkan solusi yang salah.

Roberts juga mengatakan bahwa:

Siswa yang berusaha memecahkan masalah tanpa menggunakan pengembalian eksplisit dari for loop bernasib kurang baik: hanya tujuh dari 42 siswa yang mencoba strategi ini berhasil menghasilkan solusi yang benar. Angka itu mewakili tingkat keberhasilan kurang dari 20%.

Ya, Anda mungkin lebih berpengalaman daripada siswa CS101, tetapi tanpa menggunakan pernyataan break (atau ekuivalen kembali / kebohongan dari tengah-tengah loop), pada akhirnya Anda akan menulis kode bahwa sementara yang terstruktur dengan baik cukup berbulu dalam hal logika tambahan variabel dan duplikasi kode yang seseorang, mungkin diri Anda sendiri, akan memasukkan bug logika di dalamnya ketika mencoba mengikuti beberapa ide passe dari gaya pengkodean "yang benar".

Dan ada satu masalah yang lebih besar di sini selain pernyataan return / break-type, jadi pertanyaan ini sedikit lebih luas daripada yang tentang istirahat. Beberapa mekanisme penanganan pengecualian juga melanggar paradigma titik keluar tunggal

Jadi pada dasarnya siapa pun yang berpendapat di atas bahwa prinsip sing-out masih berguna hari ini juga berdebat dengan paradigma penanganan pengecualian, kecuali digunakan dengan cara yang sangat konstruktif yang dijelaskan dalam tautan terakhir; pedoman tersebut pada dasarnya membatasi semua pengecualian dari fungsi melempar (), yaitu tidak ada propagasi pengecualian antar fungsi yang diizinkan sama sekali. Nikmati Pascal baru Anda dengan sintaksis seperti C ++.

Saya melihat dari mana gagasan "satu kembali saja" berasal?bahwa pendapat umum di situs ini adalah kebalikan dari apa yang saya posting di sini, jadi saya sepenuhnya mengerti mengapa saya telah memilih turun, meskipun saya jawaban pertama di sini untuk benar-benar memberikan sesuatu yang ditanyakan oleh pertanyaan: beberapa info tentang tes kegunaan aktual yang difokuskan pada masalah keluar tunggal. Saya kira saya tidak seharusnya membiarkan pengetahuan menghalangi prekonsepsi, terutama di situs gamification. Saya akan tetap mengedit Wikipedia mulai sekarang. Setidaknya ada info dari sumber yang baik dihargai dan klaim yang tidak jelas atau salah berpura-pura didukung oleh sumber akhirnya mendapatkan larangan. Di situs ini, yang terjadi justru sebaliknya: pendapat yang tidak berdasar oleh fakta mendominasi. Saya sepenuhnya berharap mod untuk menghapus bagian terakhir ini, tapi setidaknya cowok itu akan tahu mengapa Anda kehilangan saya selamanya sebagai kontributor di sini.


Saya tidak mencatat ini, tetapi pada Anda "Tetapi dengan melakukannya Anda mungkin harus memperkenalkan variabel tambahan dan / atau duplikasi kode yang keduanya biasanya membuat program lebih sulit untuk dipahami." titik, itu klaim subjektif. Saya setuju bahwa menambahkan duplikasi variabel atau kode membuatnya sulit untuk dipahami, tetapi menambahkan goto bisa membuatnya sulit untuk dipahami juga, ditambah lagi kerusakan yang dilakukan oleh duplikasi dapat dikurangi dengan memasukkan kode duplikat ke dalam suatu fungsi (meskipun IMO bergerak) kompleksitas ke grafik panggilan tidak secara otomatis menghilangkannya).
Steve314

Saya melihat maksud Anda tentang makalah 1995 hanya setelah komentar terakhir itu, dan memutuskan untuk mengunggulkan - poin menarik. Saya pikir downvote Anda mungkin lebih karena posting Anda panjang, dan dimulai dengan titik subjektif, jadi mungkin downvoter tidak membaca semuanya (sama seperti saya, pada awalnya). Pada dasarnya, ini adalah ide yang baik untuk memperkenalkan poin asli Anda lebih awal.
Steve314

Ngomong-ngomong, saya pikir banyak orang menganggap pengecualian sebagai semacam titik keluar alternatif alternatif - karena mereka dimaksudkan untuk kasus kesalahan (semacam) yang tidak benar-benar diperhitungkan. Saya mengerti itu agak sensitif terhadap budaya bahasa. Dalam beberapa bahasa "pengecualian" lebih dari namanya - kasus sukses luar biasa valid (dan IIRC Stroustrup mengatakan sesuatu seperti itu tentang C ++, meningkatkan poin filosofis tentang apakah kesalahan adalah kesalahan jika ditangani). Beberapa bahkan mengatakan pengecualian hanyalah aliran kontrol lain yang digunakan setiap kali memberikan aliran kontrol yang Anda butuhkan.
Steve314

1
@ Steve314 " ditambah lagi kerusakan yang dilakukan oleh duplikasi dapat dikurangi dengan memfaktorkan kode duplikat ke dalam fungsi " Menempatkan keluar dari garis dan keluar dari pandangan langsung bagian dari logika fungsi, bagian yang tidak masuk akal terisolasi. Membuatnya lebih sulit untuk memahami logika fungsi.
curiousguy

1
@curiousguy - ya, itu benar, dan mungkin bagian dari maksud saya "memindahkan kompleksitas ke grafik panggilan" titik. Agama saya adalah bahwa setiap pilihan yang Anda buat merupakan trade-off jadi waspadalah terhadap semua opsi yang masuk akal dan keuntungan dan kerugiannya, dan mengetahui mitigasi umum adalah penting tetapi berhati-hatilah seandainya obatnya lebih buruk daripada penyakitnya. Kecuali tentu saja bagian dari pertukaran itu adalah berapa banyak waktu yang Anda habiskan (atau buang-buang) untuk mempermasalahkan hal-hal.
Steve314

1

http://dl.acm.org/citation.cfm?id=1241526

http://www.springerlink.com/content/n82qpt83n8735l7t/

http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=661092

[Pertanyaan Anda sepertinya dijawab dengan satu kata, "ya". Namun, saya telah diberi tahu bahwa memberikan jawaban singkat adalah "meremehkan" pertanyaan itu. Jika Anda merasa saya menolak, beri tanda pada jawaban agar moderator dapat menghapusnya.]


1
@ luis.espinal: Menuju tujuan apa? Informasi apa yang akan berisi teks? Pertanyaannya sedikit mengoceh. Bagian mana dari pertanyaan yang harus ditanggapi dengan beberapa teks?
S.Lott

1
Sebagai soal gaya, dan mungkin untuk memberikan lebih banyak informasi yang dapat diberikan oleh abstrak tautan (mengingat bahwa kami tidak tahu apakah OP adalah anggota ACM / IEEE / Springer Verlag yang membayar dengan akses ke artikel lengkap dan menemukan jawaban untuk pertanyaannya.) Sebagai contoh, abstrak artikel ACM tidak menyebutkan gaya pengkodean. Paling-paling itu berbicara tentang menguatkan teorema program terstruktur (yang dengan sendirinya tidak berbicara tentang masalah pengembalian tunggal atau ganda). Jadi Anda bisa menjelaskan mengapa tautan itu relevan.
luis.espinal

1
Artikel ketiga (untungnya saya memiliki akses ke IEEE Xplore) sepertinya tidak berhubungan dengan apa yang diminta OP sejauh yang saya tahu. Ini adalah artikel yang luar biasa, Anda, yang saya cetak untuk bacaan yang lebih berdedikasi di lain waktu. Jadi mungkin Anda juga bisa menjelaskan bagaimana artikel ini membantu OP menjawab pertanyaannya. Secara keseluruhan, sepertinya Anda hanya melemparkan banyak tautan bersama. Ini bukan cara menolak (kecuali kalau itu niat Anda), tapi sekali lagi, saya gagal melihat bagaimana itu membantu OP. Dan inilah sebabnya seorang poster harus menambahkan beberapa teks di sepanjang tautannya. Jadi sekarang Anda tahu mengapa saya mengatakannya;)
luis.espinal

1
dari mulut OP Is a coding style principle - e.g. the single-exit principle - really a good thing?- yang memberikan konteks pada pertanyaan yang diajukannya, tentang gaya pengkodean. Selain itu, gaya pengkodean tidak sama dengan metodologi pemrograman, khususnya metode desain tingkat tinggi yang menjadi fokus artikel IEEE (dinyatakan dengan jelas oleh penulis.) Itulah mengapa saya mengatakan "tidak" - cakupannya sangat berbeda.
luis.espinal

1
Saya menduga dari mana OP berasal. Dia jelas menyatakan gaya pengkodean (bukan metodologi), dan khususnya, pengembalian tunggal vs ganda. Saya harus mengatasinya beberapa kali dengan kode yang ditulis dengan baik dan jelas dengan sendirinya menggunakan beberapa pernyataan pengembalian yang ditulis ulang menjadi versi yang lebih berbelit-belit menggunakan pengembalian tunggal (khususnya dalam organisasi besar yang berbahan merah) * sebagai per "proses". Dan orang bertanya-tanya (dan menantang bukti) keabsahan, kegunaan dan efektivitas biaya dari mandat yang sewenang-wenang tersebut. Orang-orang yang memaksakan mandat demikian masih hidup di tahun 60-an: /
luis.espinal

1

Merupakan prinsip gaya pengkodean - mis. Prinsip keluar tunggal

Orang-orang yang masih ingin keluar atau keluar ganda masih terjebak di akhir 1960-an. Saat itu, diskusi seperti itu penting karena kami masih dalam masa bayi programmer terstruktur, dan ada cukup banyak kubu yang menyatakan bahwa temuan di balik Teorema Program Terstruktur Bohm-Jacopini tidak berlaku secara universal untuk semua konstruksi pemrograman.

Itu adalah sesuatu yang harus diselesaikan sejak lama. Yah, itu telah diselesaikan (hampir 4 dekade tepatnya, baik di bidang akademik maupun industri), tetapi orang-orang (mereka yang benar-benar pro atau menentang) belum memperhatikan.

Adapun sisa jawaban saya, semuanya relatif (apa yang tidak ada dalam perangkat lunak?):

  • benar-benar hal yang baik?

Iya nih. Sebagian besar waktu untuk kasus umum, dengan peringatan khusus untuk kasus tepi dan konstruksi pemrograman khusus bahasa.

Selalu, atau kadang-kadang saja?

Sebagian besar waktu.

Seberapa besar bedanya?

Tergantung.

Kode yang dapat dibaca vs kode yang tidak dapat dibaca. Meningkatnya kompleksitas (yang seharusnya kita ketahui sekarang meningkatkan kemungkinan memperkenalkan kesalahan) vs kompleksitas yang lebih sederhana (dan ergo, probabilitas kesalahan yang lebih kecil.) Bahasa yang kompilernya tidak menambahkan pengembalian implisit (katakanlah, Pascal, Java atau C #) dan yang default ke int (C dan C ++).

Pada akhirnya, itu adalah keterampilan mengasah dengan pria / jam di belakang keyboard. Terkadang, boleh saja memiliki beberapa pernyataan pengembalian, seperti di sini (dalam beberapa kodesemu Pascal'esque):

function foo() : someType
  begin
  if( test1 == true )
  then
    return x;
  end
  doSomethignElseThatShouldnHappenIfTest1IsTrue();
  return somethingElse();
end;

Maksudnya jelas, dan algoritme cukup kecil dan cukup rumit sehingga tidak menjamin pembuatan variabel 'bendera' yang memegang nilai pengembalian akhirnya yang digunakan dalam satu titik pengembalian tunggal. Algoritme mungkin salah, tetapi strukturnya cukup sederhana sehingga upaya dalam mendeteksi kesalahan (kemungkinan besar) dapat diabaikan.

Terkadang tidak (di sini menggunakan pseudocode mirip-C):

switch(someVal)
{
case v1 : return x1;
case v2 : return x2:
case v3 : doSomething(); // fall-through
case v4: // fall-through
case v5: // fall-through
case v6: return someXthingie;
...
...
default:
   doSomething(); // no return statement yet
}

Di sini, algoritme tidak memiliki struktur sederhana, dan pernyataan sakelar (gaya C) memungkinkan langkah-langkah yang mungkin atau mungkin tidak dilakukan secara sengaja sebagai bagian dari algoritme.

Mungkin algoritme itu benar, tetapi ditulis dengan buruk.

Atau mungkin, oleh kekuatan eksternal di luar kemampuan programmer, ini adalah representasi aktual (dan benar) dari algoritma yang dibutuhkan secara sah.

Mungkin itu salah.

Untuk mengungkap kebenaran semua ini membutuhkan jauh lebih banyak upaya daripada dalam contoh sebelumnya. Dan di sinilah letak sesuatu yang sangat saya percayai (ingatlah bahwa saya tidak memiliki studi formal untuk mendukung hal ini):

Mengasumsikan cuplikan kode yang dianggap benar:

  1. Pernyataan pengembalian berganda meningkatkan keterbacaan dan kesederhanaan cuplikan kode seperti itu, jika cuplikan tersebut mewakili algoritme sederhana dengan struktur aliran yang pada dasarnya sederhana. Secara sederhana, maksud saya tidak kecil, tetapi maksud saya secara inheren dapat dipahami atau bukti diri , yang tidak memerlukan upaya membaca yang tidak proporsional (atau mendorong orang untuk muntah, mengutuk ibu seseorang, atau menelan peluru ketika mereka harus membacanya. )

  2. Pernyataan pengembalian tunggal meningkatkan keterbacaan dan kesederhanaan potongan kode tersebut jika nilai kembali dihitung sepanjang eksekusi algoritma atau jika langkah-langkah dalam algoritma yang bertanggung jawab untuk menghitungnya dapat dikelompokkan bersama dalam satu lokasi dalam struktur algoritma .

  3. Pernyataan pengembalian tunggal mengurangi keterbacaan dan kesederhanaan sepotong kode jika memerlukan penugasan ke satu atau lebih variabel bendera, dengan lokasi penugasan tersebut tidak secara seragam terletak di seluruh algoritma.

  4. Pernyataan pengembalian berganda mengurangi keterbacaan dan kesederhanaan sepotong kode jika pernyataan pengembalian tidak terdistribusi secara merata di seluruh algoritma, dan jika mereka membatasi satu sama lain blok kode yang tidak seragam dalam ukuran atau struktur di antara mereka sendiri.

Ini terkait erat dengan kompleksitas cuplikan kode yang dimaksud. Dan ini pada gilirannya terkait dengan langkah-langkah kompleksitas siklomatik dan halstead. Dari ini, seseorang dapat mengamati hal berikut:

Semakin besar ukuran subrutin atau fungsi, semakin besar dan kompleks struktur aliran kontrol internalnya, dan semakin besar probabilitas Anda akan menghadapi pertanyaan apakah akan menggunakan pernyataan pengembalian berganda atau tunggal.

Kesimpulannya adalah: jaga agar fungsi Anda tetap kecil dalam melakukan satu hal dan hanya satu hal (dan melakukannya dengan baik). Jika mereka menunjukkan metrik kompleksitas cyclomatic dan halstead nominal kecil, tidak hanya mereka pasti paling benar dan menjadi implementasi tugas yang dapat dipahami, struktur batin mereka juga akan relatif jelas.

Kemudian, dan hanya dengan begitu Anda dapat dengan mudah dan tanpa kehilangan banyak tidur, Anda dapat memutuskan apakah akan menggunakan pengembalian tunggal dan berulang tanpa menjalankan banyak risiko memperkenalkan kesalahan dengan salah satu pilihan.

Orang juga dapat melihat semua ini dan menyarankan bahwa ketika orang bergumul dengan masalah pengembalian tunggal atau pengembalian ganda, itu karena - baik karena kurangnya pengalaman, kebodohan atau kurangnya etika kerja - mereka tidak menulis kode bersih dan cenderung menulis fungsi mengerikan dengan sepenuhnya mengabaikan langkah-langkah siklomatik dan halstead.


1
Tipe pengembalian C ++ tidak default ke int: tidak ada tipe pengembalian default sehingga harus ditentukan dalam semua kasus.
Sjoerd

Dari sebelum saya menulis pertanyaan ini - programmers.stackexchange.com/questions/58237/… . Pada dasarnya, saya menganjurkan kesadaran akan prinsip tersebut, tetapi tidak secara ketat mengikutinya - jika semua titik keluarnya jelas, saya senang. Maksud saya di sini - hanya karena saya menyebutkan prinsip sebagai contoh tidak berarti saya mendukung prinsip itu, dan tentu saja tidak dalam bentuk yang ketat. Namun, pendapat subjektif saya hanya itu - mungkin ada argumen yang lebih kuat untuk pandangan saya, atau mungkin ada argumen kuat bahwa saya salah.
Steve314

Tentang "default to int"?
curiousguy

Maksud saya mengatakan, dan saya harus memenuhi syarat, bahwa kebanyakan kompiler hanya akan "mendorong" nilai register akumulator sebagai nilai kembali jika kode kebetulan memiliki cabang eksekusi tanpa nilai pengembalian eksplisit. Yang berlaku berarti mengembalikan hasil operasi aritmatika terakhir (apa pun sampah yang mungkin) dalam bentuk int. Dan itu pasti akan menjadi sampah (dan ergo, perilaku tidak terdefinisi) terlepas dari apa fungsi yang dimaksudkan untuk dilakukan di tempat pertama. C dan C ++ dapat memperingatkan Anda, tetapi kompilasi akan membiarkan Anda mengkompilasi kecuali jika Anda menggunakan -Werror atau yang serupa.
luis.espinal
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.