Syntaktisk sukker i et programmeringssprog er en syntaktisk funktion , der ikke påvirker programmets adfærd, men gør sproget mere brugervenligt.
Det kan være et hvilket som helst syntakselement, der giver programmøren en alternativ måde at skrive en syntaktisk konstruktion på allerede i sproget, som er mere bekvem, eller mere kortfattet, eller ligner en anden almindelig måde at skrive på, eller hjælper med at skrive programmer i god stil.
Syntaktisk sukker er ethvert syntaktisk element, mekanisme, beskrivelsesmetode, der er tilgængelig i et programmeringssprog, som duplikerer et andet element eller mekanisme, der er tilgængeligt på sproget, men som er mere bekvemt at bruge, eller er mere kortfattet, eller ser mere naturligt ud eller er mere velkendt ( svarende til lignende elementer på andre sprog), eller simpelthen bedre opfattet, når en person læser et program. Det centrale er, at syntaktisk sukker, teoretisk set, altid kan fjernes fra et sprog uden at miste dets evner - alt, hvad der kan skrives ved hjælp af syntaktisk sukker, kan skrives på samme sprog uden det. Syntaktisk sukker er således kun beregnet til at gøre det nemmere for programmøren at skrive programmet.
Begrebet syntaktisk sukker er stort set vilkårligt. Dets brug forudsætter, at man fra hele sættet af syntaktiske konstruktioner, der er tilgængelige i sproget, kan udskille nogle "grundlæggende sæt", der giver sprogets funktionalitet, og yderligere syntaktiske midler, som, hvis det ønskes, kan udtrykkes ved hjælp af basissættet ; sidstnævnte vil være syntaktisk sukker for et givet sprog. Mange designs er dog udskiftelige, og det er langt fra altid muligt at sige med sikkerhed, hvilke af dem der er grundlæggende, og hvilke der er yderligere. For eksempel er der fire typer sløjfer i Modula-2 : en forudsætningsløkke , en postbetingelsesløkke , en trinløkke og en ubetinget løkke . Teoretisk set kan de første tre slags cyklusser let udtrykkes i forhold til den sidste. Er de så syntaktisk sukker? Det siger de normalt ikke, selvom de formelt falder ind under ovenstående definition.
Tildelingen af nogle konstruktioner til syntaktisk sukker er tvetydig på grund af historiske årsager. For eksempel har C -sproget og dets efterkommere operatorerne increment , decrement og compound assignment ( ++, --, +=, -=og andre). Introduktionen af disse operatører i sproget var forårsaget af behovet for at understøtte manuel optimering af programmer, da koden, der bruger dem, kunne oversættes til mere effektive maskininstruktioner (“ ++a” blev oversat til én INC-instruktion, og et lignende udtryk “ a=a+1” til en hel gruppe instruktioner). Udviklingen af kodeoptimeringsteknologi har gjort en sådan manuel optimering meningsløs; nu genererer compilere den samme kode for de "lange" og "korte" versioner af operationen. Som et resultat er forkortede operatorer blevet til syntaktisk sukker, selvom de ikke var det oprindeligt.
I nogle tilfælde fortolkes begrebet "syntaktisk sukker" bredere end "en anden måde at skrive på for allerede eksisterende syntaktiske konstruktioner." Jack Crenshaw i Lad os bygge en compiler! [1] anvender dette udtryk på syntaktiske elementer, der ikke er nødvendige for den korrekte kompilering af programmet, men som er inkluderet i sproget udelukkende af hensyn til programmørens bekvemmelighed og for programmets læsbarhed:
Når alt kommer til alt, burde folk også læse programmer... Sukkertokens tjener som nyttige vartegn for at hjælpe dig med at holde styr på sporet...
Et eksempel på et sådant syntaktisk sukker er "then" i "if"-sætningen eller "do" i "while"-sætningen, såvel som et semikolon: kompilatoren bestemmer utvetydigt slutningen af betingelsen og det sted, hvor sætningen slutter uden dem, men tilstedeværelsen af disse konstruktioner gør programmet mere læsbart. Det er klart, at den snævre fortolkning af begrebet "syntaktisk sukker" er uforenelig med den brede: I C eller Pascal er det umuligt at skrive operatorer på en anden måde uden "da", "gør" og semikolon. I et sådant tilfælde er det passende at tale om " syntax garbage ". I betragtning af at ekstra ord i et programmeringssprog er ekstra tokens, ville det være mere korrekt at bruge udtrykket " leksikalsk skrald " [2] . På den anden side er det ikke helt korrekt at kalde sådanne "ekstra" elementer af sproget "skrald", fordi de i virkeligheden kan påvirke kvaliteten af programmering betydeligt, da tilstedeværelsen af redundans i syntaksen gør det lettere for compileren at lokalisere fejl i koden. Betragt et eksempel i et betinget BASIC-lignende sprog, hvor ordet så er valgfrit i den betingede sætning og et semikolon mellem sætningerne, og lighedstegnet kan afhængigt af positionen angive både logisk lighed og tildeling:
hvis a > b og k = 20 f = 10Her er "a>b og k=20" betingelsen, og "f=10" er "den" gren. Men hvis programmøren udelader eller ved et uheld fjerner "og"-operatoren, bliver konstruktionen:
hvis a > b k = 20 f = 10Programmet forbliver syntaktisk korrekt, men betingelsen vil ganske enkelt være "a>b", og "den" gren vil, afhængigt af sprogets regler, være enten "k=20", som er blevet fra en betingelse til en opgave, eller begge operatorer "k=20 f= ti". Som følge af fejlen vil betingelsen blive overtrådt, og værdien af variablen k vil blive ødelagt. Da programmet forbliver syntaktisk korrekt, når en logisk fejl introduceres, vil compileren ikke bemærke fejlen. At kræve den obligatoriske tilstedeværelse af serviceordet "da" mellem betingelsen og operatøren vil få compileren til at detektere en syntaksfejl i betingelsen. Obligatorisk semikolon mellem operatorer vil også gøre det muligt for compileren at opdage en fejl - fraværet af et semikolon efter "k=20" operatoren. Således fører tilstedeværelsen af "sukker"-tokens, ligesom enhver redundans i sproget generelt, til det faktum, at logiske fejl i koden bliver til syntaktiske og kan detekteres af compileren.
Udtrykket syntaktisk sukker blev opfundet af Peter J. Landin i 1964 for at beskrive overfladesyntaksen af et simpelt Algol-lignende sprog, semantisk defineret i termer af lambda-kalkulus applikative udtryk , efterfulgt af en rent leksikalsk erstatning af λ med . where
Arrays i C er blokke i hukommelsen . Array-elementer tilgås via en pointer til begyndelsen af hukommelsesblokken (det vil sige til begyndelsen af arrayet) og forskydningen af elementet i forhold til startadressen. Dette kan skrives uden at bruge den specielle syntaks for arrays ( a - pointer til begyndelsen af arrayet, i - element index): *(a + i), men sproget giver en speciel syntaks: a[i]. Interessant nok kan man også bruge formen i[a], hvilket er ret logisk på grund af kommutativiteten af additionsoperationen.
Operatørredefinition , understøttet af mange programmeringssprog, kan også tilskrives syntaktisk sukker . I princippet kan enhver operation indrammes som en procedure (funktion, metode). Operatørredefinition giver dig mulighed for at udføre operationer, der er oprettet af programmøren eksternt på samme måde som dem, der er indbygget i sproget [3] [4] .
Et andet eksempel på syntaktisk sukker er begrebet "egenskaber", der understøttes af mange moderne programmeringssprog. Dette refererer til erklæringen i klassen af pseudo-felter, der eksternt opfører sig som klassefelter (har et navn, type, tillad tildeling og læsning), men i virkeligheden er de ikke det. Hver egenskabsadgang oversættes af compileren til et adgangsmetodekald. Egenskaber er helt unødvendige (accessorer kan også kaldes direkte) og bruges udelukkende for nemheds skyld, da koden, der bruger egenskaber, ser noget enklere og klarere ud.
Ikke alle programmører betragter tilstedeværelsen af syntaktisk sukker i programmeringssprog og programmørernes brug af det som en velsignelse. Synspunktet for Niklaus Wirth er kendt , som deles af en del af programmeringsfællesskabet: ifølge det forværrer enhver udvidelse af sproget, der ikke er forårsaget af nødvendighed det, da det fører til komplikation af oversætteren og, følgelig til et fald i dets pålidelighed og ydeevne. Samtidig er kompleksiteten i at lære sproget og kompleksiteten i at vedligeholde programmer stigende. Derudover spiller selve det faktum, at der er yderligere syntaktiske værktøjer, ofte en provokerende rolle: det tilskynder programmøren til at ty til forskellige syntaktiske tricks i stedet for at analysere problemet dybere og implementere mere effektive algoritmer. Disse synspunkter afspejles i Oberon -familiens sprog , som er meget enkle og praktisk talt blottet for syntaktisk sukker.
Alan Perlis' aforisme er velkendt : "Syntaktisk sukker forårsager kræft i semikolon" . Semikolonet ( ), selvom det er en påkrævet del af de fleste populære programmeringssprog, selvom det er ubrugeligt i et nyt sprog, efterlades som et valgfrit element, da de fleste programmører har en stærk vane med at bruge det. I originalen spiller aforismen på konsonansen af de engelske ord semikolon ("semikolon") og colon , hvoraf sidstnævnte betyder ikke kun en tyktarm, men også tyktarmen ( tyktarmskræft - "tyktarmskræft"). ;
Oftere er kritik rettet mod individuelle, hyppigt stødte typer af syntaktisk sukker: redefinering af operationer, egenskaber, komplekse operationer (som den ternære betingede operation ). Kritikernes argumenter bunder dybest set ned til, at sådanne værktøjer faktisk ikke gør programmet enklere, klarere, mere effektivt eller kortere, men de fører til et yderligere spild af ressourcer og komplicerer opfattelsen, og derfor vedligeholdelsen af programmet.
I modsætning til "syntaktisk sukker" refererer begrebet " syntaktisk salt " ( engelsk syntaktisk salt ) [5] i programmørers jargon til teknisk ubrugelige konstruktioner i et programmeringssprog, som sprogets regler kræver at bruge, når de udfører potentielt usikkert. handlinger. De introduceres kun i sproget, så programmøren ved at bruge dem bekræfter, at den tvivlsomme handling blev foretaget af ham bevidst og ikke er en utilsigtet fejl eller et resultat af misforståelser. Ligesom "syntaktisk sukker", udvider "syntaktisk salt" ikke sprogets muligheder og er ikke nødvendig af compileren for at kompilere programmet korrekt; det er udelukkende beregnet til personer, der bruger det sprog. Et klassisk eksempel på et velkendt og meget brugt "syntaktisk salt" er de indbyggede datatypekonverteringskommandoer, der findes i næsten ethvert statisk indtastet sprog. Formelt er disse kommandoer overflødige (som klassisk C viser, hvor enhver typekonvertering er tilladt og udføres automatisk), men på sprog, hvor deres brug er obligatorisk, er programmøren tvunget til at være opmærksom, hver gang han udfører en potentielt farlig type blanding, hvilket ofte indikerer en logisk fejl i programmet. Afhængigt af programmeringssprogets strenghed kan brugen af et "syntakssalt" være påkrævet eller valgfrit. I det første tilfælde opfatter compileren sit fravær som en syntaksfejl, i det andet tilfælde udsender den en advarsel under oversættelsen, som programmøren kan ignorere.
I modsætning til "syntaktisk sukker", som udvider programmørens ytringsfrihed, indsnævrer "syntaktisk salt" det, hvilket kræver "uden grund" at skrive lange konstruktioner. Jargonfilen siger "syntaks salt er dårligt, fordi det hæver en hackers blodtryk." Når man skriver små programmer, der er oprettet og vedligeholdt af én person, kan forholdsregler virke overflødige, men i den industrielle udvikling af store softwaresystemer, der understøttes af store teams af programmører, hjælper "syntaktisk salt" ofte og ikke af højeste kvalifikation. ikke at lave fejl i udviklingen og forstå kode skrevet af andre udviklere mere effektivt.
Eksempler: