Onko goton käyttö aina kannattavaa?

Tästä on keskusteltu useita kertoja Stack Overflow -palvelussa, ja Chris Gillum tiivisti goto : n mahdolliset käyttötavat:

Toiminnosta poistuminen puhtaasti

Usein toiminnossa voit jakaa resursseja ja sinun täytyy poistua useista paikoista. Ohjelmoijat voivat yksinkertaistaa koodiaan asettamalla resurssin siivouskoodin funktion loppuun kaikki toiminnon ” poistumispisteet ” siivoustarra. Tällä tavalla sinun ei tarvitse kirjoittaa puhdistuskoodia jokaiseen funktion ” poistumispisteeseen ”.

Sisäkkäisten silmukoiden poistuminen

Jos olet sisäkkäisessä silmukassa ja sinun on irrotettava ryhmästä kaikki -silmukat, goto voi tehdä tästä paljon puhtaamman ja yksinkertaisemman kuin katkaisulausekkeet ja if-checkit.

Matala suorituskyvyn parannukset

Tämä pätee vain täydellisen kriittiseen koodiin, mutta goto-käskyt suoritetaan hyvin nopeasti ja voivat antaa sinulle vauhtia, kun siirryt funktion läpi. Tämä on kuitenkin kaksiteräinen miekka, koska kääntäjä ei yleensä voi optimoida koodia, joka sisältää gotoja.

Minä väitän, kuten monet muutkin väittävät. , että kaikissa näissä tapauksissa goto -käyttöä käytetään keinona päästä ulos nurkasta, johon itse koodattiin, ja se on yleensä oire koodista, joka voidaan korjata .

Kommentit

• Ensimmäinen ongelma on ratkaistu erittäin siististi finally -lohkoilla moderneilla kielillä ja toinen ratkaistaan otsikolla break s. Jos ’ juuttuvat kuitenkin C: hen, goto on melkein ainoa tapa ratkaista nämä ongelmat tyylikkäästi.
• Erittäin hyvät kohdat. Pidän siitä, kuinka Java sallii purkamisen useilta silmukan tasoilta
• @Chinmay – lopulta estää vain koskee 1) nykyaikaisia kieliä, joilla niitä on ja b) voit sietää yleiskustannuksia (poikkeuksellisella käsittelyllä on yleiskustannuksia. ) Toisin sanoen finally -sovelluksen käyttö on kelvollista vain näissä olosuhteissa. On hyvin harvinaisia, mutta päteviä tilanteita, joissa goto on oikea tapa edetä.
• Okei ihmiset … mikä helvetti on ero break 3 tai break myLabel ja goto myLabel. Voi, ’ on oikea vain avainsana. Jos käytät break, continue tai vastaavaa avainsanaa, olet tarttunut käyttämällä goto (Jos käytät for, while, foreach, do/loop, olet ehdollinen.)
• Tietoja heikosta suorituskyvystä – nykyaikaisen prosessorin käyttäytymistä voi olla vaikea ennustaa (pipeline, tilauksen ulkopuolinen toteutus), joten todennäköisesti 99 prosentissa tapauksista se ei ole sen arvoista tai jopa se voi olla hitaampaa. @MatthewWhited: Scoping. Jos syötät laajuuden mielivaltaisesta kohdasta, ei ole selvää (ihmiselle) mitä konstruktoreita tulisi kutsua (ongelma esiintyy myös C: ssä).

Ylemmän tason ohjausvirran rakenteet vastaavat yleensä ongelma-alueen käsitteitä. Jos / muu on johonkin ehtoon perustuva päätös. Silmukka sanoo suorittavan jonkin toiminnon toistuvasti. Jopa tauko-lauseessa sanotaan ”teimme tämän toistuvasti, mutta nyt meidän on lopetettava”.

Toisaalta goto-lauseella on taipumus vastata käynnissä olevan ohjelman, ei ongelma-verkkotunnus. Se sanoo jatkavan suoritusta määrätyssä kohdassa ohjelmassa . Koodia lukevan henkilön on pääteltävä mitä se tarkoittaa ongelmakohdassa.

Tietysti kaikki ylemmän tason rakenteet voidaan määritellä gotojen ja yksinkertaisten ehdollisten haarojen muodossa. . Se ei tarkoita, että he vain olisivat vain naamioituja. Ajattele heitä rajoitetuina gotoina – ja rajoitukset tekevät niistä hyödyllisiä. Break-lause toteutetaan hyppyksi sulkeutuvan silmukan loppuun, mutta sen ajatellaan paremmin olevan toimii koko silmukassa.

Kaikki muu on tasa-arvoinen, joten koodin, jonka rakenne heijastaa ongelma-alueen rakennetta, on helpompi lukea ja ylläpitää.

Ei ole tapauksia, joissa goto-lause on ehdottomasti pakollinen (”s vastaava lause ), mutta on tapauksia, joissa se voi olla vähiten huono ratkaisu. Nämä tapaukset vaihtelevat kielestä kieleksi riippuen siitä, mitä korkeamman tason rakenteita kieli tukee.

Esimerkiksi C: ssä uskon, että on olemassa kolme perusskenaariota, joissa goto on sopiva.

1. Katkaisu sisäkkäisestä silmukasta. Tämä olisi tarpeetonta, jos kielellä olisi merkitty tauko-lause.
2. Koodin osan (yleensä funktion rungon) poistaminen virheen tai muun odottamattoman tapahtuman sattuessa . Tämä olisi tarpeetonta, jos kielellä olisi poikkeuksia.
3. Täsmällisen äärellisen tilakoneen toteuttaminen. Tässä tapauksessa (ja luulen, että vain tässä tapauksessa) goto vastaa suoraan ongelma-alueen käsitettä siirtymällä yhdestä tilasta määritettyyn toiseen tilaan, jossa nykyinen tila on edustettuna sillä koodilohkolla, joka parhaillaan suorittaa .

Toisaalta, eksplisiittinen äärellinen tilakone voidaan toteuttaa myös kytkinlausekkeella silmukan sisällä. Tällä on se etu, että kaikki tilat alkavat samasta kohdasta koodissa, mikä voi olla hyödyllistä esimerkiksi virheenkorjauksessa.

Goton pääkäyttö kohtuullisen modernilla kielellä (joka tukee jos / else ja loops) on simuloida ohjausvuon rakennetta, joka puuttuu kielestä.

Kommentit

• Tämä on tähän mennessä paras vastaus – melko yllättävää, kysymykseen, joka on puolitoista vuotta vanha. 🙂
• +1 ” tähän mennessä parhaan vastauksen ”. — ” Goton pääasiallinen käyttö kohtuullisen modernilla kielellä (joka tukee if / else ja silmukoita) on simuloida ohjausvirta rakenna että ’ puuttuu kielestä. ”
• Switch-lause-tilakoneessa jokainen kirjoitus Ohjausarvo on todella goto. SSSM ’ s ovat usein hyviä rakenteita käytettäväksi, koska ne paratii SM-tila suoritusrakenteesta, mutta ne eivät ’ ei poista ” gotos ”.
• ” Kaikki muut ovat tasa-arvoisia. Koodin, jonka rakenne heijastaa ongelma-alueen rakennetta, on yleensä helpompi lukea ja ylläpitää. ” Olen ’ tiennyt tämän pitkään, mutta puuttui sanoja niin tarkkaan viestimiseen tavalla, että muut ohjelmoijat voivat todella ymmärtää. Kiitos tästä.
• ” jäsennelty ohjelmalause ” huvittaa minua, koska sillä on taipumus osoittaa selvästi huomauttaa, että strukturoitujen ohjelmointilausekkeiden käyttäminen goto-mallin jäljittelemiseen on paljon vähemmän luettavissa kuin pelkän goto-sovelluksen käyttäminen!

Se riippuu varmasti ohjelmointikielestä. Tärkein syy goto on ollut kiistanalainen, koska sen haitalliset vaikutukset syntyvät, kun kääntäjä antaa sinun käyttää sitä liian vapaasti. Ongelmia voi syntyä esimerkiksi, jos sen avulla voit käyttää goto -toimintoa siten, että voit nyt käyttää alustamatonta muuttujaa tai pahempaa, siirtyä toiseen menetelmään ja sotkea puhelun kanssa pino. Kääntäjän vastuulla on olla järjetön ohjausvirta.

Java on yrittänyt ”ratkaista” tämän ongelman kieltämällä kokonaan goto. Java antaa kuitenkin sinun käyttää return finally -lohkon sisällä ja aiheuttaa siten poikkeuksen tahattoman nielemisen.Sama ongelma on edelleen olemassa: kääntäjä ei tee työtä. goto poistaminen kielestä ei ole korjannut sitä.

C #: ssä goto on yhtä turvallinen kuin break, continue, try/catch/finally ja return. Se ei anna sinun käyttää alustamattomia muuttujia, se ei anna sinun hypätä ulos viimeisestä lohkosta jne. Kääntäjä valittaa. Tämä johtuu siitä, että se ratkaisee todellisen ongelman, joka on kuin sanoin järjetön ohjausvirta. goto ei peruuta maagisesti tarkan määrityksen analyysiä ja muita kohtuullisia kääntäjän tarkastuksia.

Kommentit

• Teidän mielestänne C # ’ s goto ei ole paha? Jos näin on, näin on jokaisessa rutiininomaisesti käytetyssä modernissa kielessä, jossa on goto -rakenne, ei vain C # …

Kyllä. Kun silmukat ovat sisäkkäin useita tasoja syvällä, goto on ainoa tapa katkaista tyylikkäästi sisäinen silmukka. Toinen vaihtoehto on asettaa lippu ja irrottaa jokaisesta silmukasta, jos lippu täyttää ehdon. Tämä on todella ruma ja melko virheellinen. Näissä tapauksissa goto on yksinkertaisesti parempi.

Tietysti Java-nimetty break -lauseke tekee saman asia, mutta antamatta sinun siirtyä mielivaltaiseen kohtaan koodissa, joka ratkaisee ongelman siististi sallimatta asioita, jotka tekevät goto pahaksi.

Kommentit

• goto ei ole koskaan tyylikäs vastaus. Kun silmukasi ovat sisäkkäin useita tasoja syvällä, ongelmasi on, että et suunnitellut koodiasi välttääksesi monitestattuja silmukoita. Proseduurikutsuja EI (Lue ” Lambda: The Ultimate … ” -papereita.) Goton käyttäminen silmukoiden purkamiseen sisäkkäisi useita syvä taso asettaa nauhatukea avoimeen moninkertaiseen murtumaan: se voi olla yksinkertaista, mutta se ei ole ’ oikea vastaus.
• Ja tietysti siellä ei ole koskaan pariton tapaus, kun tarvitaan syvälle sisäkkäisiä silmukoita? Hyvä ohjelmoija ei ole t vain sääntöjen noudattamisesta, mutta myös tiedosta, milloin rikkoa niitä.
• @ JohnR.Strohm Älä koskaan sano koskaan. Jos käytät ohjelmoinnissa termejä, kuten ” never ”, et ’ ole selvästi käsittelemättä kulmatapauksilla, optimoinnilla, resurssirajoituksilla jne. Syvästi sisäkkäisissä silmukoissa goto on todellakin puhtain ja tyylikäs tapa poistua silmukoista. Eikö ’ ole väliä kuinka paljon ’ olet muokannut koodiasi.
• @ JohnR.Strohm: Toiseksi eniten ohitettu ominaisuus vaihdettaessa VB.NET: stä C #: -silmukkaan Do. Miksi? Koska voin vaihtaa yhden syvää taukoa tarvitsevan silmukan Do -silmukaksi ja kirjoittaa Exit Do ja siellä ’ ei GoTo. Sisäkkäisiä silmukoita tapahtuu koko ajan. Pinoiden rikkominen tapahtuu noin% ajasta.
• @ JohnR.Strohm Ainoa syy miksi sanot ” goto, ei ole koskaan tyylikäs vastaus ” johtuu siitä, että päätit miettiä, että goto ei ole koskaan tyylikäs vastaus, joten mikään gotoa käyttävä ratkaisu ei voi olla tyylikäs vastaus.

Suurin osa lannistumisesta tapahtuu eräänlaisen ”uskonnon” muodossa, joka on luotu Jumalan Djikstran luona, joka pakotti 60-luvun alussa sen valittavaan voimaan :

• hyppää mihin tahansa koodilohkoon
  • toiminto, jota ei suoriteta alusta
  • silmukoita, joita ei suoriteta alusta
  • ohitettu muuttujan alustus
• hyppää pois mistä tahansa koodilohkosta ilman mitään mahdollista puhdistusta.

Tällä ei ole mitään muuta tekemistä goto lauseke nykyaikaisista kielistä, joiden olemassaolo johtuu vain tuesta cr muiden kuin tarjotun kielen koodirakenteiden käyttö.

Erityisesti yllä oleva ensimmäinen pääkohta on enää sallittu ja toinen puhdistetaan (jos goto ei lohko pino kelataan oikein ja kaikki oikeat hävittäjät kutsutaan)

Voit viitata tähän vastaukseen saadaksesi käsityksen siitä, kuinka parillinen koodi ei goton käyttäminen voi olla lukukelvoton. Ongelma ei ole itse goto, vaan sen huono käyttö.

Voin kirjoittaa kokonaisen ohjelman käyttämättä if, vain for. Tietenkään se ei ole hyvin luettavissa, näyttää kömpelöltä ja tarpeettomasti monimutkaiselta.

Mutta ongelma ei ole for. Se olen minä.

Asiat kuten break, continue, throw, bool needed=true; while(needed) {...} jne. huomauttavat enemmän kuin naamiaiset goto paeta pois djikstrarilaisten zeloottien piikit, että – 50 vuotta nykyaikaisten keksintöjen keksimisestä – haluavat silti vankejaan. He unohtivat, mistä Djikstra puhui, he muistavat vain hänen muistiinpanonsa otsikon (GOTO: ta pidettiin haitallisena, eikä se ollut edes hänen onw-otsikkonsa: toimittaja muutti sitä) ja syyttivät ja bash, bash ja syyttävät kaikkia tekoja, joilla nämä 4 peräkkäin sijoitettu kirje.

Nyt on vuosi 2011: on aika ymmärtää, että goto ei tarvitse ottaa huomioon GOTO lausunto, josta Djikstra oli kiinnostava.

Kommentit

• ” Tauko, jatka , heitto, bool tarvitaan = tosi; kun (tarvitaan) {…} jne. huomaavat enempää kuin naamioitu goto ” en ole ’ samaa mieltä. Haluaisin mieluummin ” asioita, kuten tauko jne., On rajoitettu goto ” tai jotain sellaista. Goton pääongelma on, että se on yleensä liian voimakas. Siinä määrin kuin nykyinen goto on vähemmän voimakas kuin Dijkstra ’ s, vastauksesi on hyvä kanssani.
• @MuhammadAlkarouri: Olen täysin samaa mieltä. Löysit juuri paremman sanamuodon ilmaisemaan tarkalleen käsitykseni. Huomautukseni on, että näitä rajoituksia ei joskus voida soveltaa, ja tarvitsemasi rajoitukset eivät ole kielellä. Sitten ” voimakas ” asia, joka on vähemmän erikoistunut, saa sinut kiertämään. Esimerkiksi Java break n ei ole käytettävissä C ++: ssa, joten goto escape, vaikka escape ei vaadita olevan vain n-ple-silmukan ulkopuolella.

Pariton jatko täällä tai siellä, niin kauan kuin se on paikallinen toiminnolle, vahingoittaa harvoin merkittävästi luettavuutta. Se hyödyttää sitä usein kiinnittämällä huomiota siihen, että tässä koodissa tapahtuu jotain epätavallista, joka vaatii jonkin verran epätavallisen ohjausrakenteen käyttöä .

Jos (paikalliset) gotot vahingoittavat merkittävästi luettavuutta, se on yleensä merkki siitä, että goto-funktio on tullut liian monimutkaiseksi.

Viimeinen goto, jonka laitoin osa C-koodista oli rakentaa pari lukittavia silmukoita. Se ei sovi normaaliin ”hyväksyttävän” goto-käytön määritelmään, mutta toiminto päätyi huomattavasti pienemmäksi ja selkeämmäksi seurauksena. Goton välttäminen olisi edellyttänyt erityisen sotkuista DRY-rikkomusta.

Kommentit

• Vastaus tähän on kaikkein vivahteikkain vanhassa ” Makaa ’ s perunalastut ” iskulause: ” Lyö vetoa, että et voi ’ syödä vain yhtä ”. Esimerkissäsi on kaksi ” lukitusta ” (mitä se tarkoittaa, ja minä ’ m vedonlyönti ei ole ’ t melko) silmukkaa, ja goto antoi sinulle halvan. Entä huoltopoika, jonka on muutettava koodia sen jälkeen, kun olet törmännyt bussiin? Aikooko goto tehdä hänen elämästään helpompaa tai vaikeampaa? Tarvitsevatko nämä kaksi silmukkaa uudelleen?

Mielestäni koko tämä asia on ollut haukkumista väärä puu.

GOTO sinänsä ei tunnu ongelmalliselta, vaan pikemminkin oire todellisesta synnistä: spagettikoodi.

Jos GOTO aiheuttaa virtauksen ohjauslinjojen merkittävä ylitys, niin se on huono jakso. Jos se ei ylitä virtauksen ohjauslinjoja, se on vaaraton. Harmaalla vyöhykkeellä, joka on välissä, on esimerkiksi loop-pelastuksia, on vielä joitain kieliä, jotka eivät ole lisänneet rakenteita, jotka kattavat kaikki legit-harmaat tapaukset. monien vuosien kohdalla on kyse silmukasta, jossa päätöspiste on silmukan keskellä. Sinulla on jäljellä joko kopioitu koodi, lippu tai GOTO. Minusta GOTO-ratkaisu on paras kolmesta. Tässä ei ole virtauksen ohjauslinjojen ylitystä, se on vaaraton.

Kommentit

• Tapaus, johon viittat, kutsutaan joskus nimellä ”puolitoista silmukkaa” tai ”N plus yksi puoli silmukkaa”, ja se on kuuluisa käyttötapa goto, jotka hyppäävät silmukkaan (jos kieli sen sallii; koska toinen tapaus, hyppääminen ulos silmukasta keskellä, on yleensä triviaalia ilman goto ).
• (Valitettavasti useimmat kielet kieltävät silmukkaan siirtymisen.)
• @KonradRudolph: Jos otat käyttöön ” -silmukan ” GOTOn kanssa ei ole muuta silmukkarakennetta, johon tulisi hypätä.
• Mielestäni goto huudahtaa OHJAUSVIRTA TÄÄLLÄ EI OLE ’ TAVALLINEN RAKENNETTU-OHJELMOINTI KUVAT . Koska jäsenneltyihin ohjelmointimalleihin sopivat ohjausvirrat on helpompi päättää kuin ne, jotka eivät ’ t, tällaisia malleja tulisi yrittää käyttää aina kun mahdollista; jos koodi sopii tällaisiin malleihin, ’ ei pitäisi huutaa, että se ei ’ t. Toisaalta, jos koodi ei todellakaan sovi tällaisiin malleihin, siitä huutaminen voi olla parempi kuin teeskentely, että koodi sopii, kun se ei todellakaan ’ t.
• @supercat No, kuvittele, että kirjoitit itsellesi aikataulun, ja sitten tuuli puhaltaa sen käsistäsi. Logiikkasi mukaan sinun ei pitäisi ’ t noutaa sitä, koska aikataulusi jälkeen ajaminen ei ollut ’ t aikataulussasi.

Kyllä, goota voidaan käyttää hyödyntämään kehittäjän kokemuksia: http://adamjonrichardson.com/2012/02/06/long-live-the-goto-statement/

Aivan kuten minkä tahansa tehokkaan työkalun (osoittimet, moniperintö jne.) kohdalla, yksi on kuitenkin kurinalaista käyttämällä sitä. Linkissä annettu esimerkki käyttää PHP: tä, joka rajoittaa goto-konstruktion käytön samaan toimintoon / menetelmään ja estää mahdollisuuden siirtyä uuteen ohjauslohkoon (esim. Silmukka, kytkinlauseke jne.)

Riippuu kielestä. Sitä käytetään edelleen laajalti esimerkiksi Cobol-ohjelmoinnissa. Olen työskennellyt myös Barionet 50 -laitteen parissa, jonka laiteohjelmointikieli on varhainen BASIC-murre, joka tietysti vaatii käyttämään Gotoa.

goto voi olla hyödyllinen, kun siirrät vanhan kokoonpanokoodin C: hen. Ensinnäkin käsky- käskyn muuntaminen C: ksi käyttämällä goto -kokoonpanoa kompressorin ”s branch -käskyn korvaajana, voi mahdollistaa erittäin nopean siirtämisen.

Kommentit

• Oikea, mutta yksi argumenteista goto vastaan on, että ne estävät kääntäjän optimoinnit.
• @Sapphire_Brick: Monet kääntäjän optimoinnit on suunniteltu tiettyjen suoritusmallien ympärille. Jos suoritettava tehtävä ei ’ ei sovi tuettuihin suoritusmalleihin, ” ” -optimoinnin estäminen ei välttämättä onnistu olla huono asia.

Vastustan ei. Ne tulisi aina korvata työkalulla, joka on tarkempi ongelmalle, jonka ratkaisemiseen gotoa käytetään (ellei sitä ole saatavana kielelläsi) .Esimerkiksi lausekkeet ja poikkeukset ratkaisevat aiemmin goto-ohjattuihin ongelmiin silmukoiden pakenemisessa ja virheiden käsittely.

Kommentit

• Minä ’ väitän, että kun kielillä on molemmat nämä ominaisuudet, goto puuttuu tyypillisesti kyseisistä kielistä.
• Mutta koska ne eivät ’ et tarvitse niitä, tai koska ihmiset luulevat tarvitsevansa niitä ’ eivät tarvitse niitä?
• Näkemyksesi ovat isoja. On monia tapauksia, joissa goto on lähinnä ongelman omaavan verkkotunnuksen semantiikkaa, mikä tahansa muu olisi likainen hakkerointi.
• @ SK-logiikka: En halua ’ ei usko, että sana ” bigoted ” tarkoittaa sitä, mitä luulet sen tarkoittavan.
• @Keith,

Sanoisin ei. Jos löydät tarpeen käyttää GOTOa, lyön vetoa siitä, että koodi on suunniteltava uudelleen.

Kommentit

• Ehkä, mutta sinä haven ’ ei antanut mitään perusteluja
• Dijkstra toimitti perustelut yksityiskohtaisesti vuosikymmeniä sitten.
• Vain dogma. Ei resoneja. Huomaa: Djikstra EI OLE ENEMMÄN VOIMASSA OLEVA RESON: se viittasi ’ 60-luvun BASIC- tai FORTRAN GOTO -lausekkeeseen. Heillä ei ole mitään tekemistä tämän päivän todella aneemisten (verrattuna niiden voimaan) robottien kanssa.
• @EmilioGaravaglia No, hänen perusteluistaan, jotka ovat edelleen voimassa nykyään, on se, että spagettikoodin kirjoittaminen ’ on erittäin helppoa käyttämällä tapaa, jolla monille kavereille. Tämän logiikan mukaan meidän ei kuitenkaan pidä ’ käyttää osoittimia, koska niin monen osoittimen käyttö kuin number of gotos needed to create problems aiheuttaisi samanlaisen kaaoksen.