4 einfache Gewohnheiten, die Bash-Skripte sofort in saubereren, übersichtlicheren Code verwandeln

Optimieren Sie Ihre Bash-Skripte mit vier einfachen Gewohnheiten, die die Lesbarkeit erhöhen und die Wartung erleichtern. Verwandeln Sie unübersichtlichen Code in klare Strukturen.

Egal, ob Sie ein Anfänger oder ein erfahrener Bash-Schreiber sind, es gibt immer Raum für neue Tipps. Einige der besten sind schnell zu lernen und verändern Ihre gesamte Herangehensweise. Ich habe vier, die Ihr Bash-Spaghetti in ein gut formatiertes Kunstwerk verwandeln.

Verteilen Sie Ihre Pipelines über mehrere Zeilen

Eine Pipeline ist eine Folge von Befehlen, die durch das "|" Zeichen verbunden sind. Jeder Befehl verarbeitet die Ausgabe des vorherigen. Normalerweise schreiben Menschen Pipelines so:

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

Obwohl funktional, fehlt es an Einheitlichkeit und ist schwer zu bearbeiten.

Der vorherige Befehl scannt das aktuelle Verzeichnis gründlich und zählt die Anzahl verschiedener Datei-Eigentümer. Es ist absichtlich lang, um eine Pipeline zu veranschaulichen. Es ist nicht der eleganteste oder effizienteste Ansatz, denn dasselbe Ergebnis können Sie mit find . -type f -printf '%u\n' | sort | uniq --count erzielen.

Beim Scannen von Quellcode (oder Text) suchen wir nach Mustern. Im obigen Beispiel haben Sie wahrscheinlich nach dem "|" Zeichen gesucht, ohne darüber nachzudenken, das die Grenzen zwischen den Befehlen definiert. Da sowohl Befehle als auch Grenzen auf derselben horizontalen Achse existieren, müssen wir Anstrengungen aufbringen, um visuell nach den Pipes zu suchen und die Teile dazwischen zu verstehen. Das ist unnötig anstrengend, also können wir zusätzlich den vertikalen Raum nutzen:

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

Unser Gehirn ist sehr gut im visuellen Verarbeiten, und wenn wir das direkt nutzen können, können wir unser Arbeitsgedächtnis freigeben, um uns auf die Absicht zu konzentrieren. Anstatt zu versuchen, herauszufinden, wo jeder Befehl beginnt und endet, sehen wir eine konsistente vertikale Linie von Pipes.

Dieser Ansatz erleichtert auch die Bearbeitung in IDEs, da diese oft erlauben, ganze Zeilen zu löschen oder zu verschieben.

Machen Sie Ihre Funktionen komponierbar

Lasst uns den vorherigen Befehl aufschlüsseln, um ihn leserlicher und komponierbar zu machen.

"Komponierbarer" Code bedeutet, dass wir unterschiedliche Elemente aus grundlegenden Bausteinen (z. B. Funktionen) zusammensetzen können – wie das Zusammensetzen einer Wand aus Ziegeln.

Zuerst möchten wir wahrscheinlich eine Funktion, die Rohwerte liefert, dann können wir darauf aufbauen:

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

Dann wollen wir etwas aus dem Ergebnis auswählen:

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

Dann zählen wir die Ausgaben:

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

Zuletzt modifizieren wir die finale Nachricht, um sie klarer zu gestalten:

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

Jetzt können wir eine Pipeline mit diesen neuen Elementen erstellen:

file_stats \ | owner \ | tally \ | clarify_ownership

Es ist nicht nur leserlicher, sondern wir können auch einzelne Elemente ändern. Zum Beispiel:

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

Mein Code ist überoptimiert, aber er dient nur zu Illustrationszwecken. In der realen Welt beginnen Sie mit größeren Funktionen und zerlegen sie nur, wenn der Bedarf entsteht.

Bevorzugen Sie Case-Anweisungen gegenüber If-Else-Blöcken, insbesondere beim Ausführen von Befehlen

Ich liebe Switch (Case) Anweisungen. If-Else-Bedingungs-Verzweigungen sehen unordentlich aus, aber Switches wirken prägnanter und fokussierter. Normalerweise verwende ich sie am Ende meines Skripts, um CLI-Argumente mit Funktionen abzugleichen (auch bekannt als Dispatcher).

Wenn wir einen Dispatcher mit gut benannten, komponierbaren Funktionen haben, erhalten wir ein Skript mit viel klarerer Absicht:

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

Es ist nicht schwierig.

Um zu sehen, was vor sich geht, müssen wir nur ein paar Zeilen ändern, um das Ergebnis vollständig zu ändern.

Ich gehe in einem anderen Artikel, den ich geschrieben habe, ausführlicher auf Fall-Dispatcher ein. Dort wird die idiomatische (natürliche oder empfohlene) Art und Weise beschrieben, wie man CLI-Argumente verarbeitet. Sie können diesen Rat mit dem, was Sie hier gelesen haben, kombinieren, um Ihren Dispatcher so ordentlich wie möglich zu gestalten.

Einzeiler für kurze bedingte Äste verwenden

Mehr Code bedeutet mehr zu lesen. Je weniger Sie schreiben, desto besser – solange es leicht verständlich ist. Wenn-Anweisungen sind ein Übel. Wenn sie unseren Code durchstreuen, um den Programmzustand zu überprüfen (auch bekannt als Assertions), könnten sie so aussehen:

if [[ "$something" == "foo" ]]; then exit 1 fi if [[ "$something_else" == "bar" ]]; then echo "'\$something_else' kann nicht 'bar' sein" exit 1 fi if ! [[ -f "$file_path" ]]; then echo "'\$file_path' muss ein Dateipfad sein" exit 1 fi

Wenn man alle bedingten Äste im restlichen Skript betrachtet, fühlt sich der obige Code an, als würde er die Lesbarkeit beeinträchtigen. Wie bereits erwähnt, glaube ich, dass Code visuell durchsuchbar sein sollte, und wir können unseren Stil variieren, um das zu erreichen. Zum Beispiel verwende ich oft den folgenden Ansatz für Assertions:

[[ "$something" == "foo" ]] && exit 1 [[ "$something_else" == "bar" ]] && { echo "'\$something_else' kann nicht 'bar' sein"; exit 1; } [[ -f "$file_path" ]] || { echo "'\$file_path' muss ein Dateipfad sein"; exit 1; }

Sie müssen ein ";" vor einem schließenden "}" einfügen.

Ich benutze diese am Anfang meines Skripts und meiner Funktionen. Wenn ich einen Einzeiler wie diesen sehe, weiß ich, dass es sich um eine Assertion und nicht um einen bedingten Ast handelt. Es hilft mir, schnell zu erfassen, was passiert, ohne genau nachzudenken. Ich kann verstehen, was der Code bedeutet, basierend auf der Fehlermeldung, daher benötige ich keine Kommentare.

Konsistenz ist der Schlüssel zur Lesbarkeit. Wenn wir sich wiederholende Muster für kleine Details verwenden, können unsere Gedanken sie ausblenden und sich auf die Absicht des Codes konzentrieren.

Wie Sie Ihren Code schreiben, ist ein entscheidender Faktor, und es geht sowohl um visuelle Ästhetik als auch um Funktionalität. Das ist wahrscheinlich eine unpopuläre Meinung, aber sie beruht auf Wissenschaft. Ja, ich behaupte das, denn wir können Parallelen zwischen der Code-Ästhetik und Benutzeroberflächen ziehen.

Die Wissenschaft des User Experience Designs (in Bezug auf Benutzeroberflächen) besteht darin, Benutzer zu ermutigen, auf eine gewünschte Weise mit einem Produkt zu interagieren. Es geht darum, Weißräume, Layouts und vieles mehr zu nutzen, um ihre Entscheidungen zu beeinflussen. Das allgemeine Prinzip besteht darin, die kognitive Belastung für den Benutzer zu reduzieren und ihm klare Signale zu senden. Mit ästhetisch ansprechendem Code streben wir dasselbe an, allerdings für den Leser.

Schreiben Sie konsistenten, klaren Code und unterscheiden Sie Elemente durch visuelle Muster – senden Sie dem Leser klare Signale, genau wie es eine gut gestaltete Benutzeroberfläche tut.

Bist du neugierig auf weitere Artikel wie 4 einfache Gewohnheiten, die Bash-Skripte sofort in saubereren, übersichtlicheren Code verwandeln? Entdecke spannende Inhalte in der Kategorie Linux.