DevOps-bootcamp · leksjon

Beste praksis for skripting og linting

Lær om kodestandarder, kommentarer og bruk av verktøy som ShellCheck for å skrive ryddige, lesbare og feilfrie Bash-skript.

Leksjon 3 av 411 trinn

Beste praksis for skripting og linting er en gratis leksjon i DevOps-bootcamp på CoddyKit. Dette er leksjon 3 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i DevOps-bootcamp, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i DevOps-bootcamp inneholder totalt 4 leksjoner.

Hvorfor bruke beste praksis for skripting?

Det er kraftig å skrive Bash-skript, men uten gode vaner kan skriptene bli vanskelige å forstå, vedlikeholde og feilsøke.

Beste praksis er retningslinjer som hjelper Dem med å skrive ren, robust og lesbar kode. De gjør skriptene Deres:

Enklere å lese: Både for Dem selv og andre.
Enklere å vedlikeholde: Lettere å oppdatere eller rette.
Mindre utsatt for feil: Vanlige feil forebygges.
Bedre for samarbeid: Måten koden ser ut og oppfører seg på, standardiseres.

Kommentering for tydelighet

Kommentarer er viktige for å forklare hvorfor koden gjør noe, ikke bare hva den gjør. De fungerer som notater for Dem selv i fremtiden eller for andre utviklere.

Bruk kommentarer til å:

Beskrive skriptets overordnede formål øverst.
Forklare kompleks logikk eller vanskelige deler.
Dokumentere funksjoner: formålet, argumentene og returverdiene.

Start en kommentar med symbolet # (hash-tegn).

#!/bin/bash
# This script demonstrates commenting best practices.
# Author: CoddyKit
# Date: 2023-10-27

# Function: greet_user
# Description: Prints a greeting message to the console.
# Arguments:
#   $1 - The name of the user to greet.
greet_user() {
  local name="$1" # Store the first argument in a local variable.
  echo "Hello, ${name}!" # Output the greeting message.
}

# Main script execution starts here.
echo "Script execution started."
greet_user "CoddyKit Learner" # Call the function with a specific name.
echo "Script execution finished."

Tydelige navnekonvensjoner

Meningsfulle navn gjør skriptet enklere å følge. Unngå variabler med ett tegn, med mindre de er vanlige løkketellere (som i eller j).

Generelle konvensjoner:

Variabler: Bruk beskrivende navn (for eksempel user_name og log_file). Bruk UPPERCASE for miljøvariabler eller globale konstanter. Bruk lowercase_with_underscores for lokale skriptvariabler.
Funksjoner: Bruk lowercase_with_underscores, ofte med et verb først (for eksempel process_data og check_status).
Skript: Bruk lowercase_with_hyphens (for eksempel backup-script.sh).

Konsekvent formatering og innrykk

Konsekvent formatering, som innrykk og mellomrom, forbedrer lesbarheten betydelig. Se for Dem å lese en bok med inkonsekvente avsnittsinnrykk!

Viktige punkter:

Bruk 2 eller 4 mellomrom til innrykk (tabulatorer frarådes ofte).
Hold linjene korte (under 80 tegn er en god tommelfingerregel for terminaler).
Bruk tomme linjer til å skille logiske kodeblokker.
Juster beslektede elementer når det er hensiktsmessig.

Det viktigste er at De er konsekvent, ikke hvilken bestemt stil De velger.

Robusthet: 'set -u' (nounset)

Alternativet set -u (eller set -o nounset) er svært nyttig for å forhindre feil som skyldes skrivefeil eller variabler som ved et uhell ikke er satt. Hvis skriptet prøver å bruke en variabel som ikke har fått en verdi, avslutter set -u skriptet umiddelbart med en feil.

Dette bidrar til å oppdage feil tidlig og hindrer uventet atferd senere i skriptet.

Prøv å kjøre koden nedenfor. Den er laget for å avsluttes tidlig fordi UNSET_NAME ikke er definert.

#!/bin/bash
# Demonstrating 'set -u' (nounset)

set -u # Exit if an unset variable is used

MY_GREETING="Hello"
echo "${MY_GREETING}, CoddyKit!"

# This variable is NOT set. With 'set -u', the script will exit here.
echo "Your name is: ${UNSET_NAME}" 

echo "This line will NOT be reached if 'set -u' is active and UNSET_NAME is indeed unset."

Robusthet: 'set -o pipefail'

Når De sender kommandoer gjennom rør (for eksempel cmd1 | cmd2 | cmd3), rapporterer Bash vanligvis bare avslutningsstatusen til den siste kommandoen i røret. Det betyr at hvis cmd1 mislykkes, men cmd2 og cmd3 lykkes, kan røret likevel rapportere suksess!

set -o pipefail endrer denne oppførselen. Hvis en hvilken som helst kommando i et rør mislykkes (returnerer en avslutningsstatus som ikke er null), blir hele rørets avslutningsstatus den samme statusen som ikke er null.

Dette gjør rørkjeder mer pålitelige ved å signalisere umiddelbart hvis en tidlig kommando mislyktes.

#!/bin/bash
# Demonstrating 'set -o pipefail'

set -o pipefail # Ensures pipe's exit status is the last non-zero command

echo "Running a failing command in a pipe:"
echo "---"

# 'false' command always fails (exit status 1).
# 'cat /dev/null' always succeeds (exit status 0).
# With 'set -o pipefail', the pipe's overall exit status will be 1 from 'false'.
false | cat /dev/null

# This line will only be reached if the pipe above succeeds.
echo "---"
echo "Script finished successfully (this line won't show if pipe failed with set -o pipefail)."

Introduserer ShellCheck

Selv med beste praksis er det lett å overse små syntaksfeil eller vanlige fallgruver. Det er her ShellCheck kommer inn!

ShellCheck er et verktøy for statisk analyse (en «linter») av skallskript. Det leser skriptet og påpeker:

Syntaksfeil.
Vanlige nybegynnerfeil.
Subtile semantiske problemer.
Problemer med portabilitet på tvers av ulike skall.

Det gir nyttige forslag, ofte med lenker til mer detaljerte forklaringer.

ShellCheck i praksis: Dårlig skript

La oss se på et skript med noen vanlige problemer. Disse fører kanskje ikke til at skriptet krasjer umiddelbart, men de er dårlig praksis eller mulige feil.

Se for Dem at De har lagret dette skriptet som bad_script.sh. For å kjøre ShellCheck på det skriver De: shellcheck bad_script.sh

Se om De klarer å finne problemene før De kjører ShellCheck!

#!/bin/bash
# A script with some common issues

MY_NAME=coddykit # Variable assignment needs no space, but quoting is good for values
echo "Hello $MY_NAME!" # Missing quotes around variable expansion

if [ $1 = "admin" ]; then # Missing quotes around $1
  echo "Welcome, administrator."
fi

# A simple loop with potential issues
for file in *.txt; do # Unquoted glob could expand to multiple arguments
  echo File: $file # Missing quotes around $file
done

Rette ShellCheck-advarsler

ShellCheck ville ha gitt ut noe som: SC2086: Double quotes missing around "$MY_NAME". Det oppgir ofte en spesifikk kode (som SC2086) som De kan slå opp for mer informasjon.

Her er det forrige skriptet, rettet i tråd med ShellChecks anbefalinger og generell beste praksis:

Legg merke til bruken av doble anførselstegn "" rundt variabelutvidelser og kommandosubstitusjoner for å forhindre orddeling og globbing, som er vanlige kilder til feil.

#!/bin/bash
# A script with issues fixed by ShellCheck

MY_NAME="CoddyKit" # Quote variable assignment values
echo "Hello ${MY_NAME}!" # Always quote variable expansions

if [ "$1" = "admin" ]; then # Quote positional parameters like $1
  echo "Welcome, administrator."
fi

# A simple loop with corrected quoting
for file in *.txt; do 
  echo "File: ${file}" # Quote variable expansions, especially in loops
done

Sjekk av beste praksis

Hvilke av følgende regnes som god praksis når De skriver Bash-skript?

Besvar den i den interaktive leksjonen

Oppsummering: Profesjonell skripting

Gratulerer! De har lært hvordan De kan løfte Bash-skriptene Deres fra å være funksjonelle til å bli profesjonelle.

Vi gikk gjennom:

Betydningen av beste praksis for lesbarhet og vedlikeholdbarhet.
Bruk av kommentarer og navnekonvensjoner for tydelighet.
Hvordan De kan gjøre skriptene robuste med set -u og set -o pipefail.
Hvordan ShellCheck automatisk kan finne problemer og forbedre koden.

Ved å bruke disse prinsippene skriver De mer pålitelige, forståelige og samarbeidsvennlige Bash-skript. Fortsett å øve!

Gratis å komme i gang

Lær deg DevOps-bootcamp med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 142
Leksjoner: 568

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Beste praksis for skripting og linting» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien DevOps-bootcamp, inkludert «Beste praksis for skripting og linting», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i DevOps-bootcamp inneholder totalt 4 leksjoner.

Hva lærer jeg i «Beste praksis for skripting og linting»?

Lær om kodestandarder, kommentarer og bruk av verktøy som ShellCheck for å skrive ryddige, lesbare og feilfrie Bash-skript. Du øver på DevOps-bootcamp med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med DevOps-bootcamp?

Ingen tidligere erfaring er nødvendig. DevOps-bootcamp på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 3 av 4.

Hvor lang tid tar leksjonen «Beste praksis for skripting og linting»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne DevOps-bootcamp-leksjonen?

Ja. Alle DevOps-bootcamp-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Feilsøking av Bash-skript (set -x, trap)
Feilhåndtering og avslutningsstatus
Beste praksis for skripting og linting
Testing av Bash-skript med Bats

← Tilbake til DevOps-bootcamp