4 enkle vaner som umiddelbart forvandler Bash-skript til renere, mer lesbar kode

Lær hvordan du kan forbedre Bash-skriptene dine med enkle tips: del pipelines, lag komponerbare funksjoner, bruk sakssetninger, og implementer en-linjer for enklere betingelser.

Enten du er nybegynner eller en erfaren Bash-skribent, er det alltid rom for å lære nye tips. Noen av de beste tar bare et øyeblikk å lære, men er så transformative at de endrer hele tilnærmingen din. Jeg har fire tips som vil forvandle din Bash-spaghetti til et velordnet kunstverk.

Spred dine pipelines over flere linjer

En pipeline er en sekvens av kommandoer knyttet sammen med "|" tegnet. Hver kommando prosesserer utdataene fra den foregående. Vanligvis skriver folk pipelines slik:

fd --type file --exec ls -l | awk '{print $3}' | grep --invert-match '^$' | sort | uniq --count | sed --regexp-extended 's/(root|user)/\1-owned files/'

Selv om den fungerer, mangler den enhetlighet og er vanskelig å redigere.

Den tidligere kommandoen skanner dypt i dagens katalog og teller opp antallet forskjellige fil eiere. Den er bevisst lang for å illustrere en pipeline. Det er ikke den mest elegante eller effektive tilnærmingen, fordi du kan oppnå de samme resultatene med find . -type f -printf '%u\n' | sort | uniq --count.

Når vi skanner kildekode (eller hvilken som helst tekst), ser vi etter mønstre. I eksemplet ovenfor så du sannsynligvis etter "|" tegnet uten å tenke, noe som definerer grensene mellom kommandoene. Imidlertid, fordi både kommandoer og grenser eksisterer på samme horisontale akse, må vi bruke energi på å søke visuelt etter rørene og forstå delene imellom. Det er unødvendig belastende, så for å frigjøre konsentrasjonen vår, kan vi i tillegg bruke vertikal plass:

fd --type file --exec ls -l \ | awk '{print $3}' \ | grep --invert-match '^$' \ | sort \ | uniq --count \ | sed --regexp-extended 's/(root|user)/\1-owned files/'

Hjernen vår er veldig god til visuell behandling, og hvis vi kan utnytte det direkte, kan vi frigjøre arbeidsminnet vårt for å fokusere på intensjonen. I stedet for å prøve å finne ut hvor hver kommando begynner og slutter, ser vi en sammenhengende vertikal linje av rør.

Denne tilnærmingen gjør det også lettere å redigere i IDE-er, fordi de ofte lar oss slette eller flytte hele linjer.

Gjør funksjonene dine komponerbare

La oss bryte ned den tidligere kommandoen for å gjøre den mer lesbar og komponerbar.

"Komponerbar" kode betyr at vi kan sette sammen ulike ting fra grunnleggende elementer (f.eks. funksjoner)—som å komponere en vegg av murstein.

Først vil vi sannsynligvis ha en funksjon som gir råverdier, deretter kan vi bygge videre på det på forskjellige måter:

file_stats() { fd --type file --exec ls -l }

Deretter vil vi plukke noe fra resultatet:

owner() { awk '{print $3}' }

Deretter teller vi opp utdataene:

tally() { grep --invert-match '^$' \ | sort \ | uniq --count }

Til slutt, modifiser den endelige meldingen for å gjøre den tydeligere:

clarify_ownership() { sed --regexp-extended 's/(root|user)/\1-owned files/' }

Nå kan vi konstruere en pipeline med disse nye elementene:

file_stats \ | owner \ | tally \ | clarify_ownership

Ikke bare er det mer lesbart, men vi kan også endre individuelle elementer. For eksempel:

clarify_date() { sed --regexp-extended 's/([[:alpha:]]+)/files modified in \1./' } mod_date() { awk '{print $6}' } file_stats \ | mod_date \ | tally \ | clarify_date

Koden min er overkomplisert, men det er kun for illustrasjonsformål. I den virkelige verden vil du starte med større funksjoner og bryte dem ned først når behovet oppstår.

Foretrekke sakssetninger fremfor if-else blokker

Jeg elsker switch (case) setninger. If-else betinget forgrening ser rotete ut, men switcher føles mer konsise og fokuserte. Jeg bruker dem vanligvis i bunnen av skriptet mitt for å matche CLI-argumenter til funksjoner (også kjent som dispatcher).

Når vi har en dispatcher med velkjente, komponerbare funksjoner, får vi et skript med mye klarere intensjoner:

case "$1" in dates) file_stats \ | mod_date \ | tally \ | clarify_date;; ownership) file_stats \ | owner \ | tally \ | clarify_ownership;; esac

Det er ikke vanskelig.

for å se hva som skjer, og vi trenger bare å endre noen få linjer for å endre resultatet helt.

Jeg utdyper om sakdistributører mer i en annen artikkel jeg har skrevet. Den beskriver den idiomatiske (naturlige eller anbefalte) måten å prosessere CLI-argumenter på. Du kan kombinere de rådene med det du har lest her for å gjøre din distributor så ryddig som mulig.

Bruk en-linjer for korte betingede grener

Mer kode betyr mer lesing. Jo mindre du skriver, jo bedre—så lenge det er lett å forstå. If-setninger er en synder. Når de sprer seg i koden vår for å sjekke programtilstand (også kalt bekreftelser), kan de se slik ut:

if [[ "$something" == "foo" ]]; then exit 1 fi if [[ "$something_else" == "bar" ]]; then echo "'\$something_else' kan ikke være 'bar'" exit 1 fi if ! [[ -f "$file_path" ]]; then echo "'\$file_path' må være en filbane" exit 1 fi

Når du vurderer alle de betingede grenene i resten av skriptet, føles den ovenstående koden som om den skaper lesbarhetsproblemer. Som nevnt tidligere, mener jeg at kode skal være visuelt skannbar, og vi kan variere stilen vår for å oppnå det. For eksempel bruker jeg ofte følgende tilnærming for bekreftelser:

[[ "$something" == "foo" ]] && exit 1 [[ "$something_else" == "bar" ]] && { echo "'\$something_else' kan ikke være 'bar'"; exit 1; } [[ -f "$file_path" ]] || { echo "'\$file_path' må være en filbane"; exit 1; }

Du må inkludere et ";" før en avsluttende "}".

Jeg bruker disse på toppen av skriptet mitt og funksjoner. Når jeg ser en en-liner som dette, vet jeg at det er en bekreftelse og ikke en betinget gren. Det hjelper meg å raskt vurdere hva som skjer, uten å tenke i det hele tatt. Jeg kan forstå hva koden betyr fra feilmeldingen, så jeg trenger ikke kommentarer.

Konsistens er nøkkelen til lesbarhet. Når vi bruker gjentakende mønstre for mindre detaljer, kan hjernen vår tune dem ut og fokusere på intensjonen bak koden.

Valget om hvordan du skriver koden din er en avgjørende faktor, og det handler like mye om visuell estetikk som om funksjonalitet. Det er sikkert en upopulær mening, men den er forankret i vitenskap. Ja, jeg hever denne påstanden, fordi vi kan dra paralleller mellom kodeestetikk og brukergrensesnitt.

Vitenskapen om brukeropplevelsesdesign (med hensyn til brukergrensesnitt) handler om å oppmuntre brukere til å samhandle med et produkt på en ønsket måte. Det innebærer å bruke hvitt rom, oppsett og mye mer for å influere deres beslutninger. Det generelle prinsippet er å redusere den kognitive byrden på brukeren og sende dem klare signaler. Med estetisk tiltalende kode, har vi som mål det samme, men for leseren i stedet.

Skriv konsistent, tydelig kode og skille elementer gjennom visuelle mønstre—send leseren klare signaler, akkurat som et godt designet brukergrensesnitt gjør.

Hvis du vil lese flere artikler som 4 enkle vaner som umiddelbart forvandler Bash-skript til renere, mer lesbar kode, kan du besøke kategorien Linux.