Et kommandolinjeverktøy

Et kommandolinjeverktøy er ofte det enkleste å skrive og det vanskeligste å gjøre bra. Denne oppskriften viser begge deler.

funksjon hjelp() {
    skriv("Bruk: hilsen <navn> [--rop]")
    skriv("")
    skriv("  <navn>   navnet som skal hilses på")
    skriv("  --rop    skriv hilsenen med store bokstaver")
}

funksjon start() -> heltall {
    la argumenter = builtin.args()
    hvis lengde(argumenter) < 2 {
        hjelp()
        returner 1
    }

    la navn = argumenter[1]
    hvis navn == "--hjelp" {
        hjelp()
        returner 0
    }

    la hilsen = "Hei, " + navn + "!"
    la i = 2
    mens i < lengde(argumenter) {
        hvis argumenter[i] == "--rop" { hilsen = builtin.upper(hilsen) }
        i = i + 1
    }

    skriv(hilsen)
    returner 0
}

Hva som skjer her

Argumentlista starter på indeks null med programnavnet, slik den gjør i de fleste språk. Det egentlige første argumentet ligger derfor på indeks én. Det er en klassisk kilde til av-med-én-feil, særlig når du senere legger til flere argumenter.

Legg merke til at hjelpeteksten ligger i sin egen funksjon. Den kalles fra to steder — når brukeren ber om den, og når de har gjort noe feil — og skal si det samme begge ganger. Det virker som en bagatell, men hjelpetekster som har kommet i utakt med hverandre er et sikkert tegn på et verktøy ingen har brukt på lenge.

Avslutningskoden er ikke pynt

Dette er den delen folk hopper over, og den som betyr mest.

returner 0 betyr at alt gikk bra. Alt annet betyr feil. Det er den eneste måten andre programmer kan vite hvordan det gikk med ditt.

Legg merke til forskjellen i eksempelet over: manglende argumenter gir 1, mens --hjelp gir 0. Det er ikke tilfeldig. Brukeren som ber om hjelp har ikke gjort noe galt — kommandoen gjorde nøyaktig det de ba om.

Et verktøy som alltid returnerer null kan ikke brukes i en pipeline. Feilen blir usynlig for skriptet som kaller det, og bygget ditt fortsetter glad videre på et resultat som ikke finnes. Har du et byggeskript som ser grønt ut mens noe åpenbart er galt, er dette det første stedet å lete.

Skriv feilmeldinger for den som leser dem

En feilmelding skal si tre ting: hva som gikk galt, hvorfor, og hva brukeren kan gjøre med det.

Sammenlign disse to:

• Feil: ugyldig argument
• Fant ikke fila konfig.toml. Oppgi stien med --konfig, eller kjør fra katalogen der fila ligger.

Den første tvinger brukeren til å gjette. Den andre løser problemet. Forskjellen er ett minutt når du skriver den, og mange minutter for hver bruker som treffer den.

Skriv feil til feilkanalen

Vanlig utdata skal kunne rørlegges videre til et annet program. Feilmeldinger skal ikke havne midt i de dataene. Skiller du de to, kan brukeren sende resultatet videre og likevel se hva som gikk galt.

Tilbake til oversikten