GOTO masih dianggap berbahaya? [Tutup]

Semua orang mengetahui Surat Dijkstra kepada editor: buka pernyataan yang dianggap berbahaya (juga di sini. Transkrip html dan di sini. Pdf) dan telah ada dorongan yang kuat sejak saat itu untuk menghindari pernyataan goto kapan pun memungkinkan. Meskipun dimungkinkan untuk menggunakan goto untuk menghasilkan kode yang luas dan tidak dapat dipelihara, namun tetap dalam bahasa pemrograman modern . Bahkan struktur kontrol lanjutan lanjutan dalam Skema dapat digambarkan sebagai goto canggih.

Keadaan apa yang menjamin penggunaan goto? Kapan sebaiknya menghindari?

Sebagai pertanyaan tindak lanjut: C menyediakan sepasang fungsi, setjmp dan longjmp, yang menyediakan kemampuan untuk pergi tidak hanya dalam frame stack saat ini tetapi dalam salah satu frame panggilan. Haruskah ini dianggap berbahaya seperti goto? Lebih berbahaya?

Dijkstra sendiri menyesalkan gelar itu, yang tidak bertanggung jawab padanya. Di akhir EWD1308 (juga di sini .pdf) ia menulis:

Akhirnya sebuah cerita pendek sebagai catatan. Pada tahun 1968, Komunikasi ACM menerbitkan teks tambang dengan judul " Pernyataan goto dianggap berbahaya ", yang pada tahun-tahun berikutnya akan paling sering dirujuk, namun sayangnya, sering oleh penulis yang tidak melihat lebih dari itu daripada yang judul, yang menjadi landasan ketenaran saya dengan menjadi templat: kita akan melihat semua jenis artikel dengan judul "X dianggap berbahaya" untuk hampir semua X, termasuk yang berjudul "Dijkstra dianggap berbahaya". Tetapi apa yang terjadi? Saya telah menyerahkan sebuah makalah dengan judul " Kasus yang menentang pernyataan kebohongan", yang, untuk mempercepat penerbitannya, editor telah berubah menjadi" surat kepada Editor ", dan dalam prosesnya ia memberinya judul baru dari penemuannya sendiri! Editornya adalah Niklaus Wirth.

Makalah klasik yang dipikirkan dengan baik tentang topik ini, untuk dicocokkan dengan Dijkstra, adalah Pemrograman Terstruktur dengan pergi ke Pernyataan , oleh Donald E. Knuth. Membaca keduanya membantu membangun kembali konteks dan pemahaman non-dogmatis tentang subjek. Dalam tulisan ini, pendapat Dijkstra tentang kasus ini dilaporkan dan bahkan lebih kuat:

Donald E. Knuth: Saya percaya bahwa dengan menyajikan pandangan seperti itu saya sebenarnya tidak setuju dengan ide-ide Dijkstra, karena dia baru-baru ini menulis yang berikut: "Tolong jangan jatuh ke dalam perangkap percaya bahwa saya sangat dogmatis tentang [the lanjut ke pernyataan]. Saya memiliki perasaan tidak nyaman bahwa orang lain membuat agama dari itu, seolah-olah masalah konseptual pemrograman dapat diselesaikan dengan satu trik, dengan bentuk disiplin kode yang sederhana! "

Pernyataan berikut adalah generalisasi; Meskipun selalu memungkinkan untuk memohon pengecualian, biasanya (menurut pengalaman dan pendapat saya yang rendah hati) tidak sebanding dengan risikonya.

1. Penggunaan alamat memori yang tidak dibatasi (baik GOTO atau raw pointer) memberikan terlalu banyak peluang untuk membuat kesalahan yang mudah dihindari.
2. Semakin banyak cara untuk sampai pada "lokasi" tertentu dalam kode, semakin kurang percaya diri tentang keadaan sistem pada saat itu. (Lihat di bawah.)
3. IMHO pemrograman terstruktur kurang tentang "menghindari GOTO" dan lebih lanjut tentang membuat struktur kode sesuai dengan struktur data. Misalnya, struktur data berulang (misalnya array, file sekuensial, dll.) Secara alami diproses oleh unit kode yang diulang. Memiliki struktur bawaan (misalnya, sementara, untuk, sampai, untuk masing-masing, dll.) Memungkinkan programmer untuk menghindari kebosanan mengulangi pola kode klise yang sama.
4. Sekalipun GOTO adalah detail implementasi level rendah (tidak selalu demikian!) Itu di bawah level yang seharusnya dipikirkan oleh programmer. Berapa banyak programmer yang menyeimbangkan buku cek pribadi mereka dalam biner mentah? Berapa banyak programmer yang khawatir tentang sektor mana pada disk yang berisi catatan tertentu, alih-alih hanya menyediakan kunci untuk mesin basis data (dan berapa banyak cara yang dapat terjadi kesalahan jika kami benar-benar menulis semua program kami dalam hal sektor disk fisik)?

Catatan kaki di atas:

Mengenai poin 2, pertimbangkan kode berikut:

a = b + 1
/* do something with a */

Pada titik "lakukan sesuatu" dalam kode, kita dapat menyatakan dengan keyakinan tinggi yang alebih besar dari b. (Ya, saya mengabaikan kemungkinan bilangan bulat bilangan bulat yang tidak terbungkus. Mari kita tidak mengurangi contoh sederhana.)

Di sisi lain, jika kode sudah dibaca dengan cara ini:

...
goto 10
...
a = b + 1
10: /* do something with a */
...
goto 10
...

Banyaknya cara untuk mendapatkan label 10 berarti bahwa kita harus bekerja lebih keras untuk menjadi percaya diri tentang hubungan antara adan bpada saat itu. (Faktanya, dalam kasus umum itu tidak dapat dipastikan!)

Mengenai poin 4, seluruh gagasan "pergi ke suatu tempat" dalam kode hanyalah metafora. Tidak ada yang benar-benar "masuk" di mana saja di dalam CPU kecuali elektron dan foton (untuk panas yang terbuang). Terkadang kita memberikan metafora untuk yang lain, lebih bermanfaat, satu. Saya ingat menemukan (beberapa dekade yang lalu!) Bahasa di mana

if (some condition) {
  action-1
} else {
  action-2
}

diimplementasikan pada mesin virtual dengan mengkompilasi action-1 dan action-2 sebagai rutinitas tanpa parameter out-of-line, kemudian menggunakan opcode VM dua argumen tunggal yang menggunakan nilai boolean dari kondisi untuk memanggil satu atau yang lain. Konsepnya hanyalah "memilih apa yang akan dipanggil sekarang" daripada "pergi ke sini atau pergi ke sana". Sekali lagi, hanya perubahan metafora.

Seorang rekan kerja saya mengatakan satu-satunya alasan untuk menggunakan GOTO adalah jika Anda memprogram diri sendiri sejauh ini ke sudut yang merupakan satu-satunya jalan keluar. Dengan kata lain, desain yang tepat sebelumnya dan Anda tidak perlu menggunakan GOTO nanti.

Saya pikir komik ini menggambarkan bahwa dengan indah, "Saya bisa merestrukturisasi aliran program, atau menggunakan sedikit 'GOTO' sebagai gantinya." GOTO adalah jalan keluar yang lemah ketika Anda memiliki desain yang lemah. Velociraptors memangsa yang lemah .

Terkadang valid untuk menggunakan GOTO sebagai alternatif untuk penanganan pengecualian dalam satu fungsi:

if (f() == false) goto err_cleanup;
if (g() == false) goto err_cleanup;
if (h() == false) goto err_cleanup;

return;

err_cleanup:
...

Kode COM tampaknya masuk ke dalam pola ini cukup sering.

Saya hanya ingat menggunakan goto sekali. Saya memiliki serangkaian lima loop terhitung bersarang dan saya harus dapat keluar dari seluruh struktur dari dalam awal berdasarkan kondisi tertentu:

for{
  for{
    for{
      for{
        for{
          if(stuff){
            GOTO ENDOFLOOPS;
          }
        }
      }
    }
  }
}

ENDOFLOOPS:

Saya bisa saja dengan mudah mendeklarasikan variabel break boolean dan menggunakannya sebagai bagian dari kondisional untuk setiap loop, tetapi dalam hal ini saya memutuskan GOTO sama praktis dan mudah dibaca.

Tidak ada velociraptors yang menyerang saya.

Kami sudah melakukan diskusi ini dan saya mendukung pendapat saya .

Selain itu, saya muak dengan orang-orang yang menggambarkan struktur bahasa tingkat tinggi sebagai “goto menyamar” karena mereka jelas tidak mengerti maksudnya sama sekali . Sebagai contoh:

Bahkan struktur kontrol lanjutan lanjutan dalam Skema dapat digambarkan sebagai goto canggih.

Itu omong kosong. Setiap struktur kontrol dapat diimplementasikan dalam hal gototetapi pengamatan ini benar-benar sepele dan tidak berguna. gototidak dianggap berbahaya karena efek positifnya tetapi karena konsekuensi negatifnya dan ini telah dieliminasi oleh pemrograman terstruktur.

Demikian pula, mengatakan "GOTO adalah alat, dan karena semua alat, itu dapat digunakan dan disalahgunakan" benar-benar melenceng. Tidak ada pekerja bangunan modern yang akan menggunakan batu dan mengklaimnya "adalah alat." Batuan telah digantikan oleh palu. gototelah digantikan oleh struktur kontrol. Jika pekerja konstruksi terdampar di alam liar tanpa palu, tentu saja dia akan menggunakan batu. Jika seorang programmer harus menggunakan bahasa pemrograman inferior yang tidak memiliki fitur X, well, tentu saja ia mungkin harus menggunakannya goto. Tetapi jika dia menggunakannya di tempat lain alih-alih fitur bahasa yang sesuai, dia jelas tidak mengerti bahasa dengan benar dan menggunakannya dengan salah. Ini sangat sederhana.

Goto sangat rendah dalam daftar hal untuk dimasukkan dalam program hanya demi itu. Itu tidak berarti itu tidak dapat diterima.

Goto bisa bagus untuk mesin negara. Pernyataan switch dalam satu loop adalah (dalam urutan kepentingan khas): (a) sebenarnya tidak mewakili aliran kontrol, (b) jelek, (c) berpotensi tidak efisien tergantung pada bahasa dan kompiler. Jadi Anda akhirnya menulis satu fungsi per negara, dan melakukan hal-hal seperti "kembalikan NEXT_STATE;" yang bahkan terlihat seperti goto.

Memang, sulit untuk kode mesin negara dengan cara yang membuatnya mudah dimengerti. Namun, tidak ada kesulitan yang berkaitan dengan penggunaan goto, dan tidak ada yang dapat dikurangi dengan menggunakan struktur kontrol alternatif. Kecuali jika bahasa Anda memiliki konstruksi 'mesin negara'. Milik saya tidak.

Pada saat-saat langka ketika algoritma Anda benar-benar paling mudah dipahami dalam hal jalur melalui urutan node (keadaan) yang dihubungkan oleh serangkaian transisi yang diizinkan (gotos), daripada oleh aliran kontrol yang lebih spesifik (loop, conditional, lainnya) ), maka itu harus eksplisit dalam kode. Dan Anda harus menggambar diagram yang cantik.

setjmp / longjmp bisa bagus untuk menerapkan pengecualian atau perilaku seperti pengecualian. Meskipun tidak dipuji secara universal, pengecualian umumnya dianggap sebagai struktur kontrol "valid".

setjmp / longjmp lebih 'berbahaya' daripada goto dalam arti bahwa mereka lebih sulit untuk digunakan dengan benar, apalagi pikiran komprehensif.

Tidak pernah ada, juga tidak akan pernah ada, bahasa apa pun di mana sedikit sulit untuk menulis kode yang buruk. - Donald Knuth.

Mengambil goto dari C tidak akan membuatnya lebih mudah untuk menulis kode yang baik dalam C. Bahkan, lebih baik melewatkan titik bahwa C seharusnya mampu bertindak sebagai bahasa assembler yang dimuliakan.

Selanjutnya akan menjadi "pointer dianggap berbahaya", kemudian "mengetik bebek dianggap berbahaya". Lalu siapa yang akan ditinggalkan untuk membela Anda ketika mereka datang untuk mengambil konstruksi pemrograman Anda yang tidak aman? Eh?

Di Linux: Menggunakan goto Dalam Kode Kernel pada Kernel Trap, ada diskusi dengan Linus Torvalds dan "orang baru" tentang penggunaan GOTO dalam kode Linux. Ada beberapa poin yang sangat bagus di sana dan Linus mengenakan kesombongan seperti itu :)

Beberapa bagian:

Linus: "Tidak, Anda telah dicuci otak oleh orang-orang CS yang berpikir bahwa Niklaus Wirth benar-benar tahu apa yang ia bicarakan. Dia tidak tahu. Dia tidak memiliki petunjuk yang menarik."

-

Linus: "Saya pikir goto baik-baik saja, dan sering lebih mudah dibaca daripada lekukan dalam jumlah besar."

-

Linus: "Tentu saja, dalam bahasa bodoh seperti Pascal, di mana label tidak bisa deskriptif, goto's bisa buruk."

Dalam C, goto hanya berfungsi dalam lingkup fungsi saat ini, yang cenderung melokalisasi bug potensial. setjmpdan longjmpjauh lebih berbahaya, bersifat non-lokal, rumit dan tergantung pada implementasi. Namun dalam praktiknya, mereka terlalu kabur dan jarang menyebabkan banyak masalah.

Saya percaya bahwa bahaya goto di C sangat dibesar-besarkan. Ingatlah bahwa gotoargumen aslinya terjadi pada zaman bahasa seperti BASIC kuno, di mana pemula akan menulis kode spageti seperti ini:

3420 IF A > 2 THEN GOTO 1430

Di sini Linus menjelaskan penggunaan yang tepat dari goto: http://www.kernel.org/doc/Documentation/CodingStyle (bab 7).

Hari ini, sulit untuk melihat masalah besar tentang GOTOpernyataan itu karena "pemrograman terstruktur" kebanyakan orang memenangkan perdebatan dan bahasa saat ini memiliki struktur aliran kontrol yang cukup untuk dihindari GOTO.

Hitung jumlah gotos dalam program C modern. Sekarang tambahkan jumlah break, continuedan returnpernyataan. Selanjutnya, tambahkan berapa kali Anda menggunakan if, else, while,switch atau case. Itu tentang berapa banyakGOTO program Anda akan memiliki jika Anda menulis dalam FORTRAN atau BASIC pada tahun 1968 ketika Dijkstra menulis suratnya.

Bahasa pemrograman pada saat itu kurang dalam aliran kontrol. Misalnya, dalam BASIC Dartmouth asli:

• IFpernyataan tidak ELSE. Jika Anda menginginkannya, Anda harus menulis:

  100 IF NOT condition THEN GOTO 200
  ...stuff to do if condition is true...
  190 GOTO 300
  200 REM else
  ...stuff to do if condition is false...
  300 REM end if
  

• Bahkan jika IFpernyataan Anda tidak memerlukan ELSE, itu masih terbatas pada satu baris, yang biasanya terdiri dari a GOTO.

• Tidak ada DO...LOOPpernyataan. Untuk non- FORloop, Anda harus mengakhiri loop dengan eksplisit GOTOatau IF...GOTOkembali ke awal.

• Tidak ada SELECT CASE. Anda harus menggunakanON...GOTO .

Jadi, Anda berakhir dengan banyak dari GOTOdalam program Anda. Dan Anda tidak dapat bergantung pada pembatasan GOTOs ke dalam satu subrutin tunggal (karena GOSUB...RETURNitu adalah konsep subrutin yang lemah), sehingga ini GOTObisa mana saja . Jelas, ini membuat aliran kontrol sulit untuk diikuti.

Dari sinilah GOTOdatangnya gerakan anti gerakan.

Go To dapat menyediakan semacam stand-in untuk penanganan pengecualian "nyata" dalam kasus tertentu. Mempertimbangkan:

ptr = malloc(size);
if (!ptr) goto label_fail;
bytes_in = read(f_in,ptr,size);
if (bytes_in=<0) goto label_fail;
bytes_out = write(f_out,ptr,bytes_in);
if (bytes_out != bytes_in) goto label_fail;

Jelas kode ini disederhanakan untuk mengambil lebih sedikit ruang, jadi jangan terlalu terpaku pada detail. Tetapi pertimbangkan alternatif yang saya lihat terlalu banyak dalam kode produksi oleh coders yang tidak masuk akal untuk menghindari penggunaan goto:

success=false;
do {
    ptr = malloc(size);
    if (!ptr) break;
    bytes_in = read(f_in,ptr,size);
    if (count=<0) break;
    bytes_out = write(f_out,ptr,bytes_in);
    if (bytes_out != bytes_in) break;
    success = true;
} while (false);

Sekarang secara fungsional kode ini melakukan hal yang sama persis. Bahkan, kode yang dihasilkan oleh kompiler hampir identik. Namun, dalam semangat programmer untuk menenangkan Nogoto (dewa teguran akademis yang ditakuti), programmer ini telah benar-benar melanggar idiom mendasar yang whilediwakili oleh loop, dan melakukan bilangan real pada keterbacaan kode.Ini tidak lebih baik.

Jadi, moral dari cerita ini adalah, jika Anda menemukan diri Anda menggunakan sesuatu yang benar-benar bodoh untuk menghindari penggunaan goto, maka jangan lakukan itu.

Donald E. Knuth menjawab pertanyaan ini dalam buku "Programate Literate", 1992 CSLI. Pada p. 17 ada esai " Pemrograman Terstruktur dengan Pernyataan goto " (PDF). Saya pikir artikel itu mungkin telah diterbitkan di buku-buku lain juga.

Artikel tersebut menggambarkan saran Dijkstra dan menjelaskan keadaan di mana ini berlaku. Tetapi dia juga memberikan sejumlah contoh counter (masalah dan algoritma) yang tidak dapat dengan mudah direproduksi menggunakan loop terstruktur saja.

Artikel ini berisi deskripsi lengkap tentang masalah, sejarah, contoh dan contoh balasan.

Goto dianggap membantu.

Saya mulai pemrograman pada tahun 1975. Bagi pemrogram era 1970-an, kata "goto dianggap berbahaya" kurang lebih mengatakan bahwa bahasa pemrograman baru dengan struktur kontrol modern layak untuk dicoba. Kami memang mencoba bahasa baru. Kami dengan cepat bertobat. Kami tidak pernah kembali.

Kami tidak pernah kembali, tetapi, jika Anda lebih muda, maka Anda tidak pernah ada di tempat pertama.

Sekarang, latar belakang dalam bahasa pemrograman kuno mungkin tidak terlalu berguna kecuali sebagai indikator usia programmer. Meskipun demikian, programmer yang lebih muda tidak memiliki latar belakang ini, sehingga mereka tidak lagi memahami pesan yang disampaikan slogan "goto dianggap berbahaya" kepada audiens yang dituju pada saat diperkenalkan.

Slogan-slogan yang tidak dimengerti tidak terlalu mencerahkan. Mungkin lebih baik melupakan slogan-slogan seperti itu. Slogan seperti itu tidak membantu.

Slogan khusus ini, "Goto dianggap berbahaya," telah mengambil nyawa mayat hidup sendiri.

Bisakah goto tidak disalahgunakan? Jawab: tentu, tapi terus kenapa? Praktis setiap elemen pemrograman dapat disalahgunakan. Yang rendah hatibool misalnya disalahgunakan lebih sering daripada yang ingin dipercaya oleh sebagian dari kita.

Sebaliknya, saya tidak ingat pernah bertemu satu pun contoh penyalahgunaan goto sejak tahun 1990.

Masalah terbesar dengan goto mungkin bukan teknis tetapi sosial. Programmer yang tidak tahu banyak kadang-kadang tampaknya merasa bahwa kebosanan membuat mereka terdengar pintar. Anda mungkin harus memuaskan programmer seperti itu dari waktu ke waktu. Begitulah hidup.

Hal terburuk tentang goto hari ini adalah tidak cukup digunakan.

Tertarik oleh Jay Ballou menambahkan jawaban, saya akan menambahkan £ 0,02 saya. Jika Bruno Ranschaert belum melakukannya, saya akan menyebutkan artikel "Pemrograman Terstruktur dengan Pernyataan GOTO" Knuth.

Satu hal yang belum pernah saya lihat dibahas adalah jenis kode yang, meskipun tidak terlalu umum, diajarkan dalam buku teks Fortran. Hal-hal seperti rentang diperpanjang dari loop DO dan subrutin kode terbuka (ingat, ini akan menjadi Fortran II, atau Fortran IV, atau Fortran 66 - bukan Fortran 77 atau 90). Setidaknya ada kemungkinan detail sintaksisnya tidak eksak, tetapi konsepnya harus cukup akurat. Cuplikan di setiap kotak berada di dalam satu fungsi.

Perhatikan bahwa buku yang sangat bagus tetapi sudah usang (dan sudah tidak dicetak) ' The Elements of Programming Style, 2nd Edn ' oleh Kernighan & Plauger menyertakan beberapa contoh nyata penyalahgunaan GOTO dari buku-buku teks pemrograman pada masanya (akhir 70-an). Namun, materi di bawah ini bukan dari buku itu.

Kisaran yang diperluas untuk loop DO

       do 10 i = 1,30
           ...blah...
           ...blah...
           if (k.gt.4) goto 37
91         ...blah...
           ...blah...
10     continue
       ...blah...
       return
37     ...some computation...
       goto 91

Salah satu alasan untuk omong kosong seperti itu adalah kartu punch kuno yang bagus. Anda mungkin memperhatikan bahwa label (baik di luar urutan karena itu gaya kanonik!) Ada di kolom 1 (sebenarnya, mereka harus di kolom 1-5) dan kode ada di kolom 7-72 ​​(kolom 6 adalah kelanjutan kolom penanda). Kolom 73-80 akan diberi nomor urut, dan ada mesin yang akan mengurutkan kartu punch menjadi urutan nomor urut. Jika Anda memiliki program Anda pada kartu berurutan dan perlu menambahkan beberapa kartu (garis) ke tengah-tengah loop, Anda harus mengulang semuanya setelah garis-garis ekstra. Namun, jika Anda mengganti satu kartu dengan barang GOTO, Anda dapat menghindari penyetelan kembali semua kartu - Anda hanya menyelipkan kartu baru di akhir rutin dengan nomor urut baru. Anggap itu sebagai upaya pertama 'komputasi hijau'

Oh, Anda mungkin juga mencatat bahwa saya curang dan tidak berteriak - Fortran IV ditulis dalam huruf besar semua secara normal.

Subrutin kode terbuka

       ...blah...
       i = 1
       goto 76
123    ...blah...
       ...blah...
       i = 2
       goto 76
79     ...blah...
       ...blah...
       goto 54
       ...blah...
12     continue
       return
76     ...calculate something...
       ...blah...
       goto (123, 79) i
54     ...more calculation...
       goto 12

GOTO antara label 76 dan 54 adalah versi goto yang dihitung. Jika variabel i memiliki nilai 1, kebagian label pertama dalam daftar (123); jika memiliki nilai 2, kebagian yang kedua, dan seterusnya. Fragmen dari 76 ke goto dihitung adalah subrutin kode terbuka. Itu adalah sepotong kode yang dieksekusi agak seperti subrutin, tetapi ditulis dalam tubuh fungsi. (Fortran juga memiliki fungsi pernyataan - yang merupakan fungsi tertanam yang dipasang pada satu baris.)

Ada konstruksi yang lebih buruk daripada goto yang dihitung - Anda bisa menetapkan label ke variabel dan kemudian menggunakan goto yang ditugaskan. Googling ditugaskan goto kepada memberi tahu saya itu dihapus dari Fortran 95. Kapur satu demi revolusi pemrograman terstruktur yang dapat dikatakan telah dimulai di depan umum dengan surat atau artikel "GOTO Considered Harmful" karya Dijkstra.

Tanpa pengetahuan tentang hal-hal yang dilakukan di Fortran (dan dalam bahasa lain, yang sebagian besar benar-benar jatuh di pinggir jalan), sulit bagi kita para pendatang baru untuk memahami ruang lingkup masalah yang ditangani oleh Dijkstra. Heck, saya tidak memulai pemrograman sampai sepuluh tahun setelah surat itu diterbitkan (tapi saya mengalami ketidakberuntungan untuk program di Fortran IV untuk sementara waktu).

Tidak ada hal-hal seperti GOTO yang dianggap berbahaya .

GOTO adalah alat, dan karena semua alat, itu dapat digunakan dan disalahgunakan .

Namun, ada banyak alat di dunia pemrograman yang cenderung disalahgunakan lebih daripada digunakan , dan GOTO adalah salah satunya. yang DENGAN pernyataan Delphi adalah hal lain.

Secara pribadi saya tidak menggunakan salah satu dari kode yang umum , tetapi saya sudah memiliki penggunaan aneh GOTO dan WITH yang dibenarkan, dan solusi alternatif akan berisi lebih banyak kode.

Solusi terbaik adalah bagi kompiler untuk hanya memperingatkan Anda bahwa kata kunci itu ternoda , dan Anda harus memasukkan beberapa arahan pragma di sekitar pernyataan untuk menghilangkan peringatan.

Ini seperti memberi tahu anak-anak Anda untuk tidak lari dengan gunting . Gunting memang tidak buruk, tetapi beberapa penggunaannya mungkin bukan cara terbaik untuk menjaga kesehatan Anda.

Tidak pernah ada, selama Anda mampu berpikir untuk diri sendiri.

Sejak saya mulai melakukan beberapa hal di kernel linux, goto tidak terlalu mengganggu saya seperti dulu. Pada awalnya saya agak ngeri melihat mereka (kernel guys) menambahkan gotos ke dalam kode saya. Sejak itu saya menjadi terbiasa dengan penggunaan goto, dalam beberapa konteks terbatas, dan sekarang kadang-kadang akan menggunakannya sendiri. Biasanya, ini adalah kebalikan yang melompat ke akhir fungsi untuk melakukan semacam pembersihan dan bail out, daripada menduplikasi pembersihan dan bailout yang sama di beberapa tempat dalam fungsi. Dan biasanya, itu bukan sesuatu yang cukup besar untuk diserahkan ke fungsi lain - misalnya membebaskan beberapa variabel malloc'ed lokal adalah kasus khas.

Saya sudah menulis kode yang hanya menggunakan setjmp / longjmp. Itu dalam program sequencer drum MIDI. Putar ulang terjadi dalam proses terpisah dari semua interaksi pengguna, dan proses pemutaran menggunakan memori bersama dengan proses UI untuk mendapatkan info terbatas yang diperlukan untuk melakukan pemutaran. Ketika pengguna ingin menghentikan pemutaran, proses pemutaran hanya melakukan longjmp "kembali ke awal" untuk memulai dari awal, alih-alih beberapa pelonggaran rumit di mana pun itu akan dieksekusi ketika pengguna ingin berhenti. Itu bekerja dengan baik, sederhana, dan saya tidak pernah memiliki masalah atau bug yang terkait dengannya dalam hal itu.

setjmp / longjmp memiliki tempat mereka - tetapi tempat itu adalah salah satu yang Anda tidak akan mungkin mengunjungi tetapi sekali dalam waktu yang sangat lama.

Sunting: Saya baru saja melihat kode. Sebenarnya siglongjmp () yang saya gunakan, bukan longjmp (bukan itu masalah besar, tapi saya lupa bahwa siglongjmp bahkan ada.)

Jika Anda menulis VM di C, ternyata menggunakan goto yang dikomputasi (gcc) seperti ini:

char run(char *pc) {
    void *opcodes[3] = {&&op_inc, &&op_lda_direct, &&op_hlt};
    #define NEXT_INSTR(stride) goto *(opcodes[*(pc += stride)])
    NEXT_INSTR(0);
    op_inc:
    ++acc;
    NEXT_INSTR(1);
    op_lda_direct:
    acc = ram[++pc];
    NEXT_INSTR(1);
    op_hlt:
    return acc;
}

bekerja jauh lebih cepat daripada saklar konvensional di dalam sebuah loop.

Karena gotodapat digunakan untuk membingungkan metaprogramming

Gotoadalah ekspresi kontrol level tinggi dan level rendah , dan sebagai hasilnya ia tidak memiliki pola desain yang sesuai yang cocok untuk sebagian besar masalah.

Ini tingkat rendah dalam arti bahwa goto adalah operasi primitif yang mengimplementasikan sesuatu yang lebih tinggi seperti whileatauforeach atau sesuatu.

Ini tingkat tinggi dalam arti bahwa ketika digunakan dengan cara tertentu dibutuhkan kode yang mengeksekusi dalam urutan yang jelas, dengan cara yang tidak terputus, kecuali untuk loop terstruktur, dan mengubahnya menjadi potongan-potongan logika yang, dengan cukup gotos, ambil -tas logika sedang disusun kembali secara dinamis.

Jadi, ada membosankan dan jahat sisi ke goto.

Sisi prosa adalah bahwa goto menunjuk ke atas dapat menerapkan loop yang sangat masuk akal dan goto menunjuk ke bawah dapat melakukan hal yang masuk akal breakatau return. Tentu saja, yang aktual while,, breakatau returnakan jauh lebih mudah dibaca, karena manusia miskin tidak perlu mensimulasikan efek gotountuk mendapatkan gambaran besar. Jadi, ide yang buruk secara umum.

Sisi jahat melibatkan rutinitas tidak menggunakan goto untuk sementara, istirahat, atau kembali, tetapi menggunakannya untuk apa yang disebut logika spageti . Dalam hal ini pengembang goto-senang membangun potongan kode dari labirin goto, dan satu-satunya cara untuk memahaminya adalah dengan mensimulasikannya secara keseluruhan, tugas yang sangat melelahkan ketika ada banyak goto. Maksud saya, bayangkan kesulitan mengevaluasi kode di mana elsetidak persis kebalikan dari itu if, di mana bersarang ifmungkin memungkinkan dalam beberapa hal yang ditolak oleh luar if, dll, dll.

Akhirnya, untuk benar-benar membahas subjek, kita harus mencatat bahwa pada dasarnya semua bahasa awal kecuali Algol awalnya hanya membuat pernyataan tunggal yang tunduk pada versi mereka if-then-else. Jadi, satu-satunya cara untuk melakukan blok bersyarat adalah gotomengelilinginya menggunakan kondisional terbalik. Gila, saya tahu, tapi saya sudah membaca beberapa spesifikasi lama. Ingat bahwa komputer pertama diprogram dalam kode mesin biner jadi saya kira segala jenis HLL adalah penyelamat; Saya kira mereka tidak terlalu pilih-pilih tentang fitur HLL apa yang mereka dapatkan.

Setelah mengatakan semua yang saya gunakan untuk memasukkan satu gotoke setiap program saya menulis "hanya untuk mengganggu para puritan" .

Menolak penggunaan pernyataan GOTO kepada programmer seperti memberi tahu tukang kayu untuk tidak menggunakan palu karena dapat merusak dinding saat dia memalu paku. Seorang programmer sejati Mengetahui Bagaimana dan Kapan menggunakan GOTO. Saya telah mengikuti di belakang beberapa yang disebut 'Program Terstruktur' ini. Saya telah melihat kode Horrid hanya untuk menghindari penggunaan GOTO, sehingga saya bisa menembak programmer. Ok, untuk membela pihak lain, saya telah melihat beberapa kode spaghetti sungguhan juga, para programmer itu juga harus ditembak.

Ini hanya satu contoh kecil dari kode yang saya temukan.

  YORN = ''
  LOOP
  UNTIL YORN = 'Y' OR YORN = 'N' DO
     CRT 'Is this correct? (Y/N) : ':
     INPUT YORN
  REPEAT
  IF YORN = 'N' THEN
     CRT 'Aborted!'
     STOP
  END

-----------------------ATAU----------------------

10:  CRT 'Is this Correct (Y)es/(N)o ':

     INPUT YORN

     IF YORN='N' THEN
        CRT 'Aborted!'
        STOP
     ENDIF
     IF YORN<>'Y' THEN GOTO 10

"Di tautan ini http://kerneltrap.org/node/553/2131 "

Ironisnya, menghilangkan goto memperkenalkan bug: panggilan spinlock dihilangkan.

Makalah asli harus dianggap sebagai "GOTO Tanpa Syarat Dianggap Berbahaya". Itu khususnya menganjurkan bentuk pemrograman berdasarkan pada conditional ( if) dan iterative ( while) constructs, daripada test-and-jump yang umum pada kode awal. gotomasih berguna dalam beberapa bahasa atau keadaan, di mana tidak ada struktur kontrol yang sesuai.

Tentang satu-satunya tempat yang saya setujui Goto dapat digunakan adalah ketika Anda perlu menangani kesalahan, dan setiap titik tertentu kesalahan terjadi memerlukan penanganan khusus.

Misalnya, jika Anda mengambil sumber daya dan menggunakan semaphore atau mutex, Anda harus mengambilnya secara berurutan dan Anda harus selalu melepaskannya dengan cara yang berlawanan.

Beberapa kode memerlukan pola yang sangat aneh untuk mengambil sumber daya ini, dan Anda tidak bisa hanya menulis struktur kontrol yang mudah dipelihara dan dipahami untuk menangani dengan baik pengambilan dan pelepasan sumber daya ini untuk menghindari jalan buntu.

Selalu mungkin untuk melakukannya dengan benar tanpa kebohongan, tetapi dalam kasus ini dan beberapa lainnya, kebalikannya sebenarnya adalah solusi yang lebih baik terutama untuk keterbacaan dan pemeliharaan.

-Adam

Salah satu penggunaan GOTO modern adalah oleh kompiler C # untuk membuat mesin negara untuk enumerator yang ditentukan oleh pengembalian hasil.

GOTO adalah sesuatu yang harus digunakan oleh kompiler dan bukan programmer.

Sampai C dan C ++ (di antara pelaku lainnya) telah memberi label istirahat dan berlanjut, goto akan terus memiliki peran.

Jika GOTO itu sendiri jahat, kompiler akan menjadi jahat, karena mereka menghasilkan JMP. Jika melompat ke blok kode, terutama mengikuti pointer, secara inheren jahat, instruksi RETurn akan menjadi jahat. Sebaliknya, kejahatan berpotensi untuk disalahgunakan.

Kadang-kadang saya harus menulis aplikasi yang harus melacak sejumlah objek di mana setiap objek harus mengikuti urutan rumit negara dalam menanggapi peristiwa, tetapi semuanya pasti single-thread. Urutan khas negara, jika direpresentasikan dalam pseudo-code adalah:

request something
wait for it to be done
while some condition
    request something
    wait for it
    if one response
        while another condition
            request something
            wait for it
            do something
        endwhile
        request one more thing
        wait for it
    else if some other response
        ... some other similar sequence ...
    ... etc, etc.
endwhile

Saya yakin ini bukan hal baru, tetapi cara saya menanganinya dalam C (++) adalah mendefinisikan beberapa makro:

#define WAIT(n) do{state=(n); enque(this); return; L##n:;}while(0)
#define DONE state = -1

#define DISPATCH0 if state < 0) return;
#define DISPATCH1 if(state==1) goto L1; DISPATCH0
#define DISPATCH2 if(state==2) goto L2; DISPATCH1
#define DISPATCH3 if(state==3) goto L3; DISPATCH2
#define DISPATCH4 if(state==4) goto L4; DISPATCH3
... as needed ...

Kemudian (dengan asumsi awalnya 0) mesin state terstruktur di atas berubah menjadi kode terstruktur:

{
    DISPATCH4; // or as high a number as needed
    request something;
    WAIT(1); // each WAIT has a different number
    while (some condition){
        request something;
        WAIT(2);
        if (one response){
            while (another condition){
                request something;
                WAIT(3);
                do something;
            }
            request one more thing;
            WAIT(4);
        }
        else if (some other response){
            ... some other similar sequence ...
        }
        ... etc, etc.
    }
    DONE;
}

Dengan variasi pada ini, mungkin ada CALL dan RETURN, sehingga beberapa mesin negara dapat bertindak seperti subrutin mesin negara lainnya.

Apakah ini tidak biasa? Iya. Apakah perlu belajar dari pihak pengelola? Iya. Apakah pembelajaran itu membuahkan hasil? Aku pikir begitu. Bisakah itu dilakukan tanpa GOTO yang melompat ke blok? Nggak.

Saya menghindarinya karena rekan kerja / manajer pasti akan mempertanyakan penggunaannya baik dalam ulasan kode atau ketika mereka sengaja menemukannya. Meskipun saya pikir itu menggunakan (misalnya kasus penanganan kesalahan) - Anda akan bertabrakan dengan beberapa pengembang lain yang akan memiliki beberapa jenis masalah dengan itu.

Itu tidak layak.

Saya benar-benar menemukan diri saya terpaksa menggunakan goto, karena saya benar-benar tidak bisa memikirkan cara yang lebih baik (lebih cepat) untuk menulis kode ini:

Saya memiliki objek yang kompleks, dan saya perlu melakukan beberapa operasi padanya. Jika objek berada dalam satu keadaan, maka saya bisa melakukan versi cepat dari operasi, kalau tidak saya harus melakukan versi lambat dari operasi. Masalahnya adalah bahwa dalam beberapa kasus, di tengah operasi yang lambat, adalah mungkin untuk menyadari bahwa ini bisa dilakukan dengan operasi cepat.

SomeObject someObject;    

if (someObject.IsComplex())    // this test is trivial
{
    // begin slow calculations here
    if (result of calculations)
    {
        // just discovered that I could use the fast calculation !
        goto Fast_Calculations;
    }
    // do the rest of the slow calculations here
    return;
}

if (someObject.IsmediumComplex())    // this test is slightly less trivial
{
    Fast_Calculations:
    // Do fast calculations
    return;
}

// object is simple, no calculations needed.

Ini adalah bagian penting dari kode UI waktu nyata, jadi saya benar-benar berpikir bahwa GOTO dibenarkan di sini.

Hugo

Hampir semua situasi di mana goto dapat digunakan, Anda dapat melakukan hal yang sama menggunakan konstruksi lain. Lagipula Goto digunakan oleh kompiler.

Saya pribadi tidak pernah menggunakannya secara eksplisit, tidak perlu.

Satu hal yang saya tidak melihat dari salah satu jawaban di sini adalah bahwa solusi 'goto' sering lebih efisien dari satu solusi pemrograman terstruktur sering disebutkan.

Pertimbangkan kasus banyak-bersarang-loop, di mana menggunakan 'goto' bukan sekelompok if(breakVariable) bagian jelas lebih efisien. Solusi "Letakkan loop Anda dalam suatu fungsi dan gunakan kembali" seringkali sama sekali tidak masuk akal. Jika loop menggunakan variabel lokal, Anda sekarang harus melewati semuanya melalui parameter fungsi, berpotensi menangani banyak sakit kepala tambahan yang muncul dari itu.

Sekarang perhatikan kasus pembersihan, yang sering saya gunakan sendiri, dan sangat umum sehingga diduga bertanggung jawab atas struktur coba {} catch {} tidak tersedia dalam banyak bahasa. Jumlah pemeriksaan dan variabel tambahan yang diperlukan untuk mencapai hal yang sama jauh lebih buruk daripada satu atau dua instruksi untuk melakukan lompatan, dan sekali lagi, solusi fungsi tambahan bukanlah solusi sama sekali. Anda tidak dapat memberi tahu saya bahwa itu lebih mudah dikelola atau lebih mudah dibaca.

Sekarang ruang kode, penggunaan tumpukan, dan waktu eksekusi mungkin tidak cukup berarti dalam banyak situasi bagi banyak programmer, tetapi ketika Anda berada di lingkungan yang tertanam dengan hanya 2KB ruang kode untuk bekerja, 50 byte instruksi tambahan untuk menghindari satu yang didefinisikan dengan jelas 'goto' hanya bisa ditertawakan, dan ini bukanlah situasi yang jarang seperti yang diyakini oleh banyak programmer tingkat tinggi.

Pernyataan bahwa 'goto berbahaya' sangat membantu dalam bergerak menuju pemrograman terstruktur, bahkan jika itu selalu merupakan generalisasi berlebihan. Pada titik ini, kita semua sudah cukup mendengarnya untuk berhati-hati menggunakannya (sebagaimana seharusnya). Ketika itu jelas alat yang tepat untuk pekerjaan itu, kita tidak perlu takut akan hal itu.

Anda dapat menggunakannya untuk memecah dari loop yang sangat bersarang, tetapi sebagian besar waktu kode Anda dapat di refactored menjadi lebih bersih tanpa loop yang terlalu dalam.