Programmering

Java går

Der er en gammel programmeringsjoke, der går sådan her: En programmerer i vrede siger til den anden programmør, "Gå til helvede!" Den anden programmør svarer i åbenlyst frastødning, "Ugh, du brugte goto!" Pointen med denne nørdede humor er, at brugen af ​​"goto" for mange programmører næsten er den værste lovovertrædelse, man kan begå.

Der er flere grunde til, at goto holdes i så lav agtelse blandt softwareudviklere. Edsger W. Dijkstras papir A Case Against the GO TO-erklæringen er en relativt tidlig afhandling om ondskabet til GOTO-misbrug. I den artikel siger Dijkstra, "[jeg blev] overbevist om, at go to statement skulle afskaffes fra alle programmeringssprog på 'højere niveau'." Dijkstras Go To-erklæring betragtes som et skadeligt brev, sprængte ikke kun goto-erklæringen, men startede også en populær datalogisk tendens med at bruge sætningen "betragtes som skadelig" (selvom disse to ord tilsyneladende blev brugt uden for programmering før det).

Mange programmører siden Dijkstra er blevet bidt af nogle af vedligeholdelsesproblemerne forbundet med brug af goto-udsagn på visse sprog. Andre programmerere har hørt disse historier eller har fået "Du skal ikke bruge goto" banket så meget ind i dem, at de ikke behøver at opleve dens ulemper på førstehånds at tro, at de ikke skal bruge GOTO.

Selvom goto-erklæringen ser ud til at have et generelt dårligt ry, er det ikke uden sine tilhængere. Frank Rubin skrev et svar på Dijkstra's Gå til erklæring, der betragtes som skadelig (Marts 1968) kaldet GOTO betragtes som skadelig 'betragtes som skadelig (marts 1987). I dette brev skrev Rubin om Dijkstras brev, der havde en indvirkning på programmører, der var så dramatiske, at "forestillingen om, at GOT0 er skadelig, accepteres næsten universelt uden tvivl." Om denne iagttagelse skrev Rubin, "Dette har forårsaget uberegnelig skade på programmeringsfeltet, som har mistet et effektivt værktøj. Det er som slagtere, der forbyder knive, fordi arbejdere undertiden klipper sig selv." Bemærk, at Dijkstra svarede på Rubins brev med On a Somewhat Desappointing Correspondance. Cunningham & Cunningham Wiki-siden Gå til siger dette om goto-udsagnet: "Lærlingen bruger det uden at tænke. Svejsmanden undgår det uden at tænke. Skibsføreren bruger det eftertænksomt."

Der er mange andre ressourcer, der dækker fordele og ulemper ved at bruge goto-erklæringen. Jeg har ikke til hensigt at genvinde denne debat her bortset fra den korte præsentation af den tidlige historie om den kontrovers, der allerede er dækket. Jeg har hørt nogle Java-udviklere, der siger, at Java ikke har en goto-erklæring, og det er det, jeg vil diskutere i resten af ​​dette blogindlæg.

Java reserverer "goto" som et reserveret nøgleord. Det er dog et ubrugt nøgleord. Hvad dette betyder er, at selv om nøgleordet faktisk ikke gør noget produktivt, er det også et ord, der ikke kan bruges i kode til navne på variabler eller andre konstruktioner. For eksempel kompileres følgende kode ikke:

pakke dustin. eksempler; / ** * Klasse, der viser Java's goto-lignende funktionalitet. * / offentlig klasse JavaGotoFunctionality {/ ** * Hovedfunktionsfunktion. * * @paramargumenter Kommandolinjeargumenter: ingen forventes. * / public static void main (final String [] argumenter) {final String goto = "Gå i seng!"; }} 

Hvis jeg forsøger at kompilere den kode, ser jeg en fejl som den, der vises i næste skærmbillede.

Fejlmeddelelsen "forventet" med en markør i rummet før "goto" giver en erfaren Java-udvikler nok af et fingerpeg til hurtigt at indse, at der er noget galt med at bruge "goto." Det kan dog ikke være så indlysende for nogen, der er nye til Java.

Jeg bruger generelt ikke goto-konstruktionen, men jeg anerkender også, at der er situationer, hvor brugen af ​​den giver kode, der er mere læselig og bruger mindre vanvittige løsninger end ikke at bruge den. I Java er dette også blevet realiseret, og der ydes støtte til nogle af de mest almindelige situationer, hvor en goto-erklæring ville være mest nyttig og sandsynligvis faktisk ville være at foretrække frem for alternativer. De mest oplagte eksempler på dette er mærket pause og mærket Blive ved udsagn. Disse diskuteres og demonstreres i afsnittet Java Tutorials forgreningserklæringer.

Evnen til at mærke en bestemt erklæring og derefter have pause eller Blive ved gælder for denne erklæring snarere end dens mest øjeblikkelige erklæring (som en umærket pause eller Blive ved gør) er især nyttig i tilfælde, hvor indlejrede sløjfer ellers ville kræve mere kode og mere kompleks kode for at opnå det samme. Jeg har fundet ud af, at jeg ofte kan redesigne mine datastrukturer og kode for at undgå sådanne situationer, men det er ikke altid praktisk.

En anden god ressource relateret til brugen af ​​goto-lignende funktionalitet i Java er 13. juni 2000 JDC Tech Tip Goto Statements og Java Programming. Som dette tip påpeger, kan etiketterne faktisk bruges til enhver blok og er ikke begrænset til pause og Blive ved. Det er dog min erfaring, at nødvendigheden af ​​denne tilgang uden for pause og Blive ved er langt mindre almindelig.

En vigtig bemærkning om etiketter er, at kodeudførelse ikke bogstaveligt talt vender tilbage til den etiket, når bryde et mærke udføres. I stedet går eksekveringsstrømmen til erklæringen umiddelbart efter den mærkede erklæring. For eksempel hvis jeg havde en ydre til loop kaldet "dustin:", så en pause i det ville faktisk gå til den første eksekverbare erklæring efter slutningen af ​​den mærket til løkke. Med andre ord fungerer det mere som en "gå til udsagnet efter den mærkede udsagn" -kommando.

Jeg giver ikke eksempler på brug af disse mærket pause eller mærket Blive ved udsagn her, fordi der er masser af gode eksempler, der let kan findes online. Specifikt inkluderer de to ressourcer, jeg allerede har nævnt (Java Tutorials Branching Statements and Goto Statements and Java Programming Tech Tip), enkle illustrative eksempler.

Jo mere jeg arbejder i softwareudviklingsbranchen, jo mere overbevist bliver jeg om, at der er få absolutter i softwareudvikling, og at ekstremistiske holdninger næsten altid vil være forkerte på et eller andet tidspunkt. Jeg viger generelt væk fra brugen af ​​goto eller goto-lignende kode, men der er tidspunkter, hvor det er den bedste kode til jobbet. Selvom Java ikke har direkte goto-support, leverer den goto-lignende support, der opfylder de fleste af mine relativt sjældne behov for sådan support.

Denne historie, "Java's goto" blev oprindeligt udgivet af JavaWorld.