Goto kullanmak her zaman değerli midir?

gotoneredeyse evrensel olarak cesareti kırılmıştır. Bu ifadeyi kullanmak hiç değerli mi?

Bu, Stack Overflow'da birkaç kez tartışıldı ve Chris Gillum , olası kullanımlarını özetledigoto :

Bir fonksiyondan temiz bir şekilde çıkma

Genellikle bir işlevde, kaynakları tahsis edebilir ve birden fazla yerden çıkmanız gerekebilir. Programcılar kaynak temizleme kodunu fonksiyonun sonuna yerleştirerek kodlarını basitleştirebilirler, fonksiyonun tüm “çıkış noktaları” temizleme etiketine girer. Bu sayede, fonksiyonun her "çıkış noktasına" temizleme kodu yazmanız gerekmez.

Yuvalanmış döngülerden çıkma

Yuvalanmış bir döngü içindeyseniz ve tüm döngülerden ayrılmanız gerekiyorsa, bir goto break ifadelerinden ve if-check'lerden çok daha temiz ve basit hale getirebilir.

Düşük seviye performans iyileştirmeleri

Bu, yalnızca kritik kodlarda geçerlidir, ancak goto ifadeleri çok hızlı bir şekilde çalışır ve bir işlev içinde ilerlerken size bir destek verebilir. Ancak bu, iki ucu keskin bir kılıçtır, çünkü bir derleyici genellikle goto içeren kodu optimize edemez.

Diğerlerinin de iddia ettiği gibi, tüm bu durumlarda, kullanımının gotobir köşeden çıkmak için kendini bir araç haline getirmenin bir aracı olarak kullanıldığını ve genellikle yeniden düzeltilebilecek bir kod belirtisi olduğunu savunuyorum.

Daha yüksek seviye kontrol akış yapıları, problem alanındaki kavramlara karşılık gelme eğilimindedir. Bir if / else, bazı koşullara dayanan bir karardır. Bir döngü tekrar tekrar bazı eylem gerçekleştirmek için diyor. Bir mola bile olsa, "bunu tekrar tekrar yapıyorduk ama şimdi durmamız gerekiyor" diyor.

Öte yandan, bir goto ifadesi, sorun alanındaki değil, çalışan programdaki bir konsepte karşılık gelme eğilimindedir. Programda belirtilen noktada yürütmeye devam edeceğini söylüyor . Kodu okuyan birinin , problem alanına göre ne anlama geldiğini çıkarması gerekir.

Tabii ki tüm üst düzey yapılar, gotos ve basit koşullu dallar olarak tanımlanabilir. Bu, sadece kılık değiştirdikleri anlamına gelmez. Onları sınırlı gotos olarak düşünün - ve bu onları faydalı kılan kısıtlamalardır. Bir break ifadesi, kapatma döngüsünün sonuna bir atlama olarak uygulanır, ancak döngü üzerinde bir bütün olarak çalışması daha iyi düşünülür.

Diğer her şey eşittir, yapısı problem alanının yapısını yansıtan kodun okunması ve bakımı daha kolay olma eğilimindedir.

Bir goto ifadesinin kesinlikle gerekli olduğu durumlar yoktur ( bu etkiye yönelik bir teorem vardır), fakat bunun en kötü çözüm olabileceği durumlar vardır. Bu durumlar, dilin hangi seviyeyi desteklediğine bağlı olarak dilden dile değişir.

Örneğin C'de, bir goto'nun uygun olduğu üç temel senaryo olduğuna inanıyorum.

1. Yuvalanmış bir döngüden kopma. Dilin etiketli bir break ifadesi olsaydı bu gereksiz olurdu.
2. Bir hata veya beklenmeyen bir olay durumunda bir kod genişliğinden (tipik olarak bir işlev gövdesi) kurtulma. Dil istisnalar olsaydı, bu gereksiz olurdu.
3. Açık bir sonlu durumlu makinenin uygulanması. Bu durumda (ve sanırım, sadece bu durumda), bir goto doğrudan mevcut durumdaki hangi kod bloğunun yürütüldüğü mevcut durumun temsil edildiği bir durumdan belirli bir duruma geçerek problem alanındaki bir konsepte tekabül eder .

Öte yandan, açık bir sonlu durumlu makine, bir döngü içindeki bir switch ifadesi ile de uygulanabilir. Bunun, her durumun kodda, örneğin hata ayıklama için yararlı olabilecek aynı yerden başlaması avantajı vardır.

Bir goto'nun oldukça modern bir dilde (eğer / başkalarını ve döngüleri destekleyen) ana kullanımı, dilde eksik olan bir kontrol akışı yapısını simüle etmektir.

Elbette bu programlama diline bağlı. Asıl neden gototartışmalı olmuştur, derleyici onu çok liberal bir şekilde kullanmanıza izin verdiğinde ortaya çıkan kötü etkilerinden kaynaklanmaktadır. Örneğin, gotobaşka bir yönteme atlamak ve çağrı yığınıyla uğraşmak için şimdi başlatılmamış bir değişkene erişebilecek veya daha kötüsü kullanmanıza izin verecek şekilde kullanabiliyorsanız, sorunlar ortaya çıkabilir . Saçma sapan kontrol akışına izin vermemek derleyicinin sorumluluğunda olmalıdır.

Java, bu sorunu gototamamen reddederek bu sorunu “çözmeye” çalıştı . Bununla birlikte, Java returnbir finallyblok içinde kullanmanıza izin verir ve bu nedenle de yanlışlıkla yutulması için bir istisna oluşturur. Aynı sorun hala var: derleyici işini yapmıyor. Dilden kaldırmak gotoonu çözmedi.

C # gotogüvenli gibidir break, continue, try/catch/finallyve return. Başlatılmamış değişkenleri kullanmanıza izin vermiyor, sonunda bir bloktan atlamanıza vb. İzin vermiyor. Derleyici şikayet edecek. Bunun sebebi , saçma sapan kontrol akışında söylediğim gibi gerçek sorunu çözmesidir. gotokesin atama analizini ve diğer makul derleyici kontrollerini sihirli bir şekilde iptal etmez.

Evet. Döngüleriniz birkaç seviye derinlikte iç içe gotoolduğunda, bir iç döngüden zarif bir şekilde ayrılmanın tek yolu budur. Diğer seçenek, bir bayrak koyar ve eğer bu bayrak bir koşulu yerine getirirse her döngüden kopar. Bu gerçekten çirkin ve oldukça hata eğilimli. Bu gibi durumlarda, gotosadece daha iyidir.

Tabii ki, Java'nın etiketli breakifadesi aynı şeyi yapar, ancak kodda rastgele bir noktaya atlamanıza izin vermeden, bu, gotokötülük yapan şeylere izin vermeden sorunu düzgünce çözer .

Bu caydırıcılığın çoğu, 60'lı yılların başlarında, ayrım gözetmeyen gücüyle ilgili olarak zorlayan Tanrı Djikstra'nın yarattığı bir tür "din" den geliyor:

• herhangi bir kod bloğuna herhangi bir yere atlamak
  • işlev başlangıçtan itibaren çalıştırılmadı
  • döngüler baştan başlamaz
  • atlanan değişken başlatma
• Herhangi bir kodlama bloğundan uzaklaşmadan, herhangi bir olası temizlik işlemi yapılmadan

Bunun goto, sadece dilin sağladığı dilden başka kod yapılarının oluşturulmasını desteklemesi nedeniyle var olan modern dillerin ifadesi ile ilgisi yoktur .

Özellikle, yukarıdaki ilk ana noktaya artık izin verilir ve ikincisi temizlenir ( gotobir bloktan çıkarsanız yığın uygun şekilde çözülür ve tüm uygun yıkıcılar çağırılır)

Goto kullanmıyorsanız bile kodun nasıl okunamadığı hakkında bir fikir edinmek için bu cevaba başvurabilirsiniz . Sorun kendiliğinden değil, kötü kullanımından kaynaklanıyor.

Ben kullanmadan bütün bir program yazabilirsiniz ifsadece for. Tabii ki, iyi okunaklı olmayacak, sakar ve gereksiz yere karmaşık bir görünüm.

Ancak sorun değil for. Benim.

Yapılacaklar sever break, continue, throw, bool needed=true; while(needed) {...}, vb birden belirterek vardır Maskeli goto -50 yaş Modern laguages- icadından sonra hala esirlerini istediğiniz, Djikstrarian fanatik Scimitars uzak kaçmaya. Djikstra'nın ne hakkında konuştuğunu unuttular, yalnızca notunun başlığını hatırladılar (GOTO zararlı olduğunu düşünüyordu ve onw unvanı bile değildi: editör tarafından değiştirildi) ve bunlara sahip olan her yapıyı suçlayıp bash, bash ve suçluyorlar. mektup sırayla yerleştirilir.

2011: Djikstra'nın zorlayıcı gotoolduğu GOTOifadesiyle uğraşmadığını anlamanın zamanı geldi.

Burada ya da oradaki gariplik, bir fonksiyonun yerel olduğu sürece, nadiren okunabilirliği önemli ölçüde zedelemektedir. Genellikle, bu kodda alışılmadık bir kontrol yapısının kullanılmasını gerektiren olağandışı bir şeyin olduğuna dikkat çekerek fayda sağlar.

Eğer (yerel) goto'lar okunabilirliğe önemli ölçüde zarar veriyorsa, bu genellikle gotoyu içeren fonksiyonun çok karmaşıklaştığının bir işaretidir.

Bir C koduna koyduğum son geçiş, bir çift birbirine geçen ilmekler oluşturmaktı. Normal "kabul edilebilir" kullanım tanımına uymuyor, ancak sonuç olarak işlev çok daha küçük ve netleşti. Goto önlemek için özellikle dağınık bir DRY ihlali gerekirdi.

Bence bu mesele yanlış ağacın havlanmasıyla ilgili bir durum.

GOTO benim için sorunlu görünmüyor, ama daha ziyade gerçek bir günah belirtisi: spagetti kodu.

GOTO, akış kontrol hatlarının ana geçişine neden olursa, o zaman kötüdür. Akış kontrol çizgilerini geçmezse zararsızdır. Aradaki gri bölgede döngü kurtarmaları gibi şeylere sahibiz, hala tüm yasal gri kasaları kapsayan yapılar eklememiş bazı diller var.

Kendimi yıllarca kullandığımı tespit ettiğim tek vaka, karar noktasının döngünün ortasında olduğu döngünün durumu. Yinelenen kod, bayrak veya GOTO ile bıraktınız. GOTO çözümünü üçün en iyisi buluyorum. Burada hiçbir akış kontrol çizgisi geçilmez, zararsızdır.

Evet, goto geliştiricinin deneyiminden yararlanmak için kullanılabilir: http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

Bununla birlikte, herhangi bir güçlü araçta (işaretçiler, çoklu kalıtım vb.) Olduğu gibi, birinin de disipline edilmesi gerekir. Bağlantıda verilen örnek, goto yapısının kullanımını aynı işleve / yönteme kısıtlayan ve yeni bir kontrol bloğuna (örneğin, loop, switch deyimi, vb.) Atlamayı engelleyen PHP kullanır.

Dile bağlıdır. Örneğin, Cobol programlamada hala yaygın olarak kullanılmaktadır. Ayrıca, firmware programlama dili, tabii ki Goto'yu kullanmanızı gerektiren bir BASIC lehçesi olan bir Barionet 50 cihazında da çalıştım.

Hayır derdim. GOTO kullanımına ihtiyaç duyuyorsanız, kodun yeniden tasarlanması gereği olduğuna bahse girerim.

gotoEski montajcı kodunu C'ye taşırken faydalı olabilir. İlk örnekte, gotomontajcının branchtalimatının yerine geçen C'ye talimat talimatı dönüşümü çok hızlı bir şekilde yerleştirmeyi sağlayabilir.

Hayır diyebilirim. Her zaman goto'nun çözmek için kullandığı soruna daha özel bir araçla değiştirilmelidir (sizin dilinizde mevcut değilse). Örneğin, break cümleleri ve istisnalar, daha önce döngüden kaçış ve hata yönetimi problemlerini çözer.