Norscode-syntaks

Denne siden er laget som en praktisk inngang til språket. Målet er ikke bare å vise enkeltstående kodebiter, men å gjøre det tydelig hvordan Norscode leses og hvordan du skriver små programmer som er lette å forstå og bygge videre på.

Hvis du er ny i språket, er det lurt å tenke på syntaks som to ting samtidig: hvordan koden skrives, og hvordan den bør leses. Norscode er laget for at kontrollflyt, typer og funksjoner skal være eksplisitte nok til at koden fortsatt føles tydelig når den blir større enn noen få linjer.

Hvordan syntaksen er tenkt å føles

Norscode er bygget for å være lesbart. Derfor er ord som funksjon, hvis, ellers og returner skrevet tydelig, og mange grunnleggende typer har norske navn. Dette gjør at koden skal være lettere å lese også når prosjektene blir større.

Poenget er ikke bare at syntaksen skal se ryddig ut. Den skal også gjøre det enklere å forstå hva som er data, hva som er regler og hva som er flyt i programmet. Når disse tingene blir tydelige tidlig, blir resten av dokumentasjonen lettere å bruke.

1. Variabler og grunnleggende typer

De fleste programmer starter med noen få verdier. I Norscode deklarerer du dette tydelig med la, navn, type og verdi.

la tittel: tekst = "Norscode"
la pris: heltall = 12000
	la aktiv: bool = sann
	la tjenester: liste_tekst = ["Nettside", "Rådgivning", "Videreutvikling"]

Den viktigste fordelen med å skrive type eksplisitt tidlig er at koden blir enklere å lese og lettere å feilsøke når noe ikke oppfører seg som forventet.

For mange nybegynnere er dette også stedet der språket begynner å gi mening. Når navn, type og verdi står samlet, blir det lettere å se hva programmet faktisk arbeider med i hver linje.

2. Kontrollflyt

hvis brukes når koden skal velge mellom to eller flere veier. mens brukes når noe skal repeteres så lenge en betingelse er sann.

hvis pris > 10000 da {
    skriv("Større oppdrag")
} ellers {
    skriv("Mindre oppdrag")
}

la teller: heltall = 0
mens (teller < 3) {
    skriv("Iterasjon: " + tekst_fra_heltall(teller))
	    teller = teller + 1
	}

Når du er ny i språket, er det lurt å holde slike blokker korte og tydelige. Hvis en hvis-blokk blir stor, er det ofte et tegn på at noe bør flyttes ut i en funksjon.

Kontrollflyt er lettest å forstå når hvert valg uttrykker én tydelig regel. Hvis en betingelse blir vanskelig å lese høyt, er det ofte et signal om at du bør gi deler av uttrykket egne navn eller bryte logikken opp i mindre funksjoner.

3. Boolske uttrykk

Boolsk logikk brukes til regler og beslutninger. Kombinasjonen av sann, usann, og og eller dekker mye av det du trenger i vanlig forretningslogikk.

la mva_sjekk: bool = pris > 1000
la har_support: bool = aktiv og mva_sjekk

	hvis har_support da {
	    skriv("Kan tilby service")
	}

Det viktige her er ikke bare at uttrykkene fungerer, men at de er lette å tolke. Mange små variabler med gode navn er ofte bedre enn ett stort uttrykk som krever mye mental parsing hver gang det leses.

4. Operatorer og uttrykk

Et uttrykk bør være lett å lese uten at man må regne i hodet flere steg samtidig. Når uttrykk blir for lange, er det ofte bedre å gi mellomregningen et navn.

la grunnpris: heltall = 1000
la kampanje: bool = sann

la endelig: heltall = grunnpris
hvis kampanje da {
    endelig = grunnpris - 200
	}

	skriv("Endelig pris: " + tekst_fra_heltall(endelig))

Dette er en viktig vane tidlig i språket. Lesbarhet kommer ofte av at du tør å introdusere en ekstra variabel når det gjør meningen klarere. Kompakt kode er ikke alltid bedre kode.

5. Lister og iterasjon

Lister brukes når du håndterer flere verdier av samme type. Det kan være produkter, tjenester, rader fra en fil eller data som skal vises på en side.

la pakker: liste_tekst = ["Basic", "Growth", "Enterprise"]

la i: heltall = 0
mens (i < lengde(pakker)) {
    skriv("Pakke: " + pakker[i])
	    i = i + 1
	}

Når du itererer over lister, er det spesielt viktig å holde indeks og stoppbetingelse riktig. Mange nybegynnerfeil skjer akkurat her.

Det kan være nyttig å lese slike løkker som en liten rytme: startposisjon, stoppregel, arbeid per runde og oppdatering av indeks. Når de fire delene er tydelige, blir også feil lettere å finne.

6. Funksjoner som neste steg

Når du ser at samme logikk kan brukes flere steder, bør du flytte den inn i en funksjon. Da blir koden lettere å teste og enklere å gjenbruke.

funksjon beregn_rabattpris(total: heltall, rabatt: heltall) -> heltall {
    hvis rabatt < 0 eller rabatt > 100 da {
        returner total
	    }
	    returner total - (total * rabatt / 100)
	}

Funksjoner er også en måte å gi regler navn på. Når en regel står i en funksjon med et tydelig navn, blir resten av koden ofte mye lettere å lese, fordi detaljene flyttes ut av hovedflyten.

Vanlige feil i starten

De fleste slike feil er små, men de blir frustrerende hvis man ikke ser mønsteret. Derfor er det lurt å lese feilmeldinger rolig og gå tilbake til den siste linjen du faktisk forsto fullt ut. Ofte ligger feilen i et lite hopp i syntaks eller i en type som ikke stemmer med det du trodde.

En enkel sjekkliste før du går videre

• Er variabler deklarert tydelig med riktig type?
• Er betingelser lesbare uten at du må tolke dem flere ganger?
• Er gjentatt logikk flyttet ut i en funksjon?
• Har du minst én liten test for det viktigste regnestykket eller regelen?

Hvis du kan svare ja på disse spørsmålene, har du allerede mye av grunnlaget på plass. Da blir neste steg i språket mindre et spørsmål om syntaks og mer et spørsmål om struktur og gode vaner.

Mini-øvelse

funksjon månedlig_verdi(engang: heltall, antall: heltall) -> heltall {
    returner engang / antall
}

test "månedlig verdi" {
	    la pris: heltall = månedlig_verdi(12000, 12)
	    assert_eq(pris, 1000)
	}

Denne lille øvelsen kombinerer flere av de viktigste byggesteinene på én gang: funksjon, parametre, returverdi og test. Når dette føles tryg