Jetzt testen

5 PowerShell Scripting Best Practices – Vom lauffähigen zum professionellen Code

Inhaltsverzeichnis

Post Featured Image

Wie viel Zeit durftest du schon damit verbringen Code deiner Kollegen oder deines Vorgängers zu entschlüsseln? Oftmals versteckt sich hinter dem Code-Chaos gar keine Rocket Science, sondern simple Funktionen, die nur auf den ersten Blick komplex aussehen.

CodeGolfing ist vielleicht auf Reddit witzig und erspart in der Konsole Zeit, hat in professionellen Scripts aber nichts zu suchen. Vielmehr sollte man dem Konzept der Einfachheit folgen – das Motto heißt hier: „Dont make me think!“.

Eine Codezeile, bei der dein horizontaler Scrollbalken ins Schwitzen kommt, durch mehrere übersichtliche Codezeilen zu ersetzen wird deinen Kollegen viel Frust ersparen. In diesem Artikel zeige ich dir 5 Best Practices, mit denen du professionellen PowerShell Code schreibst, der dir Übersichtlichkeit, Stabilität und Kompatibilität bringt.

 

 

1. Ordentliche Formatierung

Der PowerShell-Interpreter kennt keine schöne Formatierung – sämtlicher Code wird stupide nacheinander abgearbeitet. Du könntest also theoretisch deinen gesamten Code in eine Zeile schreiben, solange du einzelne Statements mit einem „;“ trennst. Der Leserlichkeit ist damit aber definitiv nicht geholfen und spätestens wenn du zu einem späteren Zeitpunkt noch einmal an deinem Code arbeiten möchtest, wirst du diese Entscheidung bereuen.

Vor allem zu Beginn ihrer PowerShell-Karriere neigen User dazu keine Konsistenz in ihrer Formatierung zu haben. Hier ein direkter Vergleich zwischen unformatiertem Code (Abbildung 1) und formatiertem Code (Abbildung 2):

Detail eines PowerShell-Scripts: Alle Codezeilen sind am Zeilenanfang ausgerichtet.

Fig. 1: Unformatted PowerShell code

 
Detail of a PowerShell script: The bracketed code is indented

Fig. 2: PowerShell code formatted in brace style

Wie du in Abbildung 2 siehst, geben Einrückungen deinem Text mehr Struktur und Scriptblöcke können optisch voneinander unterschieden werden. Ein Leerzeichen zwischen Operatoren (+, =, usw.) sorgt ebenso für besseren Überblick.

Beim Einleiten von Scriptblöcken gehen die Meinungen stark auseinander. Ich bin Fan vom „One True Brace Style“ – die öffnende geschweifte Klammer steht am Ende des einleitenden Statements, die schließende steht in einer separaten Zeile unter dem ersten Zeichen des einleitenden Statements. VSCode oder verschiedene Code-Beautifier können dir hier durch Auto-Format-Features manuelle Arbeit abnehmen.

 

2. Einsatz von Kommentaren

Sei ehrlich, auch du musstest schon deinen eigenen Code durchdenken, nachdem du ihn nach einem halben Jahr erweitern wolltest. Code-Kommentare geben dir und deinen Kollegen die Möglichkeit, Erklärungen zu einzelnen Funktionen als Notiz im Code zu hinterlassen.

Kommentare werden mit einem Hashtag/Raute/Doppelkreuz (Bezeichnungen aufsteigend nach Altersgruppe sortiert 😉) eröffnet.

Kommentare über mehrere Zeilen werden mit geöffnet und mit #> geschlossen (siehe Abbildung 3). Viele Editoren bieten auch Features an, um markierte Zeilen per Hotkey auszukommentieren (VSCode: Strg + Shift + 7):

Detail view of a multiline comment within a PowerShell script

Abb. 3: Ein PowerShell-Kommentar der über mehrere Zeilen geht

Aber Achtung: Hier besteht die Gefahr des „Over Commenting“ – nicht alles im Code muss kommentiert werden. Überlege dir welche Code-Zeilen nicht auf den ersten Blick verständlich sind und fokussiere dich auf diese.

Neben den genannten Features können auch Funktionen durch Kommentare Metainformationen zugewiesen werden. Stichwörter an dieser Stelle sind „Parameterblock“ „Synopsis“ und „Notes“. Diese werden in der ScriptRunner ActionPacks vorbildlich gepflegt.

Durch diese Metainformationen können Hilfen über Get-Help abgefragt werden. Die Texte sind natürlich frei wählbar und auf die Modul- oder Funktionsinhalte anzupassen. Die Informationen sind hierbei in der jeweiligen Funktion zu pflegen. Ein Beispiel für eine Funktion, welche Dateien um eine Dateiendung ergänzt könnte zum Beispiel wie in Abbildung 4 aussehen:

Screenshot of a PowerShell function that contains an extensive list of meta information within a comment

Abb. 4: PowerShell-Funktion mit ausführlichen Metainformationen innerhalb eines Kommentars

Über Get-Help kann ein PowerShell-Admin weitere Metainformationen abfragen (Abbildung 5):

PowerShell output of the Get-Help cmdlet. A list of meta information is displayed.

Abb. 5: Ausgabe des Get-Help Cmdlets

 

3. Verwendung verständlicher Variablennamen und Konventionen

Ich bekenne mich schuldig – auch ich benutze hin und wieder $a, $b und manchmal sogar $c beim initialen Schreiben meiner Scripte. Aber nur im ersten Entwicklungsschritt.

Variablen-Namen sollten spätestens beim Release sprechend sein und ihren Inhalt offenbaren. Listen sollten im Plural, einzelne Elemente im Singular benannt werden – $user ist nun mal etwas anderes als $users.

PowerShell ist nicht Case-sensitive – das bedeutet aber nicht, dass du alle möglichen Variationen mischen solltest. Welche Konvention du wählst, bleibt dir überlassen – Hauptsache du bleibst dabei! Folgende Konventionen haben sich über sämtliche Sprachen hinweg durchgesetzt:

$snake_case
$PascalCase
$camelCase
$sHungarianNotation  # 's' at beginning means 'String'

 

4. Kein Hard-Coding!

Hard-Coding in Scripts ist eines der schwerwiegendsten Anti-Pattern! Es macht deinen Code nicht nur adynamisch und starr, es kann auch ein gefährliches Sicherheitsrisiko darstellen!

Ich habe schon viele Admins kennengelernt, die Usernamen und sogar Passwörter oder Keys als Klartext in Scripts hinterlegt haben. Vielen fehlt es in dem Bereich an Know-how. Das Zauberwort in diesem Kontext heißt „Übergabe-Parameter“.  Informationen können somit von außen an das Script weitergereicht werden:

Code snippet in which information is passed to a PowerShell script via parameter binding

Mehr zu zum Thema CmdletBinding kannst du in den Artikel „Erweiterte Funktionen in PowerShell“ und „Parameter Binding Konzepte in PowerShell“ nachlesen.

Beim Script-Aufruf werden über die Parameter die benötigten Informationen mitgegeben. ScriptRunner Software Plattform kann beispielsweise auf einen sicheren Passwort-Safe zugreifen und dem Script somit Passwörter ohne Sicherheitsrisiko übermitteln – das Feature nennt sich „Passwort Server Connector“.

 

5. Splatting von Parametern

In vielen Fällen benötigt man viele Parameter hinter einem Cmdlet. Das sieht nicht nur unschön aus, es führt auch oftmals dazu, dass Codezeilen sehr lang werden und man sich unelegant dem horizontalen Scrollbalken bedienen muss.

Hashtables können dabei helfen deinen Code ungemein zu vereinfachen. Die Technik, auf dich ich anspiele, nennt sich Splatting. Ziel dabei ist es, Parameter innerhalb von einer Hashtable zusammenzufassen.

Wenn wir beispielsweise einen Service-Owner über den Neustart seines Servers per Mail benachrichtigen möchten (siehe Abbildung 7), benötigen wir eine Vielzahl von Parametern (durch den „Back-Tic“ am Ende der ersten Zeile konnte ich den Code für den Screenshot auf zwei Zeilen strecken):

Detail view of a PowerShell command passing a set of parameters.

Abb. 7: Befehl ohne PowerShell Splatting, bei dem Parameter und Werte einzeln aufgeführt werden.

Viel schöner lässt sich dieselbe Funktionalität mit einer Hashtable, wie in Abbildung 8,

darstellen (zur Übersicht wurden Werte hierbei hard-coded):

Abb. 8: Derselbe Befehl mit PowerShell Splatting. Parameter und Werte befinden sich in einer Hashtable, welche wiederum an den Befehl übergeben wird.

Dieses Verfahren ist bei sämtlichen Cmdlet-Parametern möglich und macht deinen Code durch den gewonnenen Überblick wartbarer.

 

Fazit und Video

Diese genannten Best Practices stellen eine gute Grundlage für übersichtlichen Code dar. Vor allem Einsteiger und mittlere Fortgeschrittene sollten diese Praktiken aufgrund der oben genannten Vorteile direkt in ihren Code implementieren und sich nicht nur auf reine Funktionalität beschränken.

In vielen IT-Landschaften liegt außerdem Code-Standard vor – Scripts werden somit vor Veröffentlichung auf Konventionen und Qualität-Standards geprüft.

In meinem Video habe ich die 5 Best Practices noch mal zusammengefasst. Viel Spaß beim Zuschauen!

Über den Autor: