Ausdrücklich empfohlene Entwicklungsrichtlinien

Artikel
10/07/2021

In diesem Abschnitt werden Richtlinien beschrieben, die Sie beim Schreiben Ihrer Cmdlets befolgen sollten. Sie sind in Richtlinien zum Entwerfen von Cmdlets und Richtlinien zum Schreiben ihres Cmdlet-Codes getrennt. Möglicherweise werden Sie feststellen, dass diese Richtlinien nicht für jedes Szenario gelten. Wenn sie jedoch angewendet werden und Sie diese Richtlinien nicht befolgen, haben Ihre Benutzer möglicherweise eine schlechte Erfahrung, wenn sie Ihre Cmdlets verwenden.

Entwurfsrichtlinien

Die folgenden Richtlinien sollten beim Entwerfen von Cmdlets befolgt werden, um eine konsistente Benutzererfahrung zwischen der Verwendung Ihrer Cmdlets und anderen Cmdlets sicherzustellen. Wenn Sie eine Entwurfsrichtlinie finden, die für Ihre Situation gilt, sehen Sie sich die Coderichtlinien für ähnliche Richtlinien an.

Verwenden eines bestimmten Nomens für einen Cmdlet-Namen (SD01)

Bei der Cmdlet-Benennung verwendete Nomen müssen sehr spezifisch sein, damit der Benutzer Ihre Cmdlets entdecken kann. Stellen Sie generischen Nomen wie "server" eine verkürzte Version des Produktnamens voran. Wenn ein Nomen beispielsweise auf einen Server verweist, auf dem eine Instanz von Microsoft SQL Server, verwenden Sie ein Nomen wie "SQLServer". Die Kombination aus bestimmten Nomen und der kurzen Liste der genehmigten Verben ermöglicht es dem Benutzer, Funktionen schnell zu entdecken und zu antizipieren und gleichzeitig eine Duplizierung zwischen Cmdlet-Namen zu vermeiden.

Um die Benutzerfreundlichkeit zu verbessern, sollte das Nomen, das Sie für einen Cmdlet-Namen auswählen, singular sein. Verwenden Sie beispielsweise den Namen Get-Process anstelle von Get-Processes . Es ist am besten, diese Regel für alle Cmdlet-Namen zu befolgen, auch wenn ein Cmdlet wahrscheinlich mehr als ein Element verwendet.

Verwenden von Pascal Case für Cmdlet-Namen (SD02)

Verwenden Sie pascal case für Parameternamen. Mit anderen Worten: Schreiben Sie den ersten Buchstaben des Verbs und alle im Substantiv verwendeten Begriffe groß. Beispiel: „Clear-ItemProperty“.

Richtlinien für den Parameterentwurf (SD03)

Ein Cmdlet benötigt Parameter, die die Daten empfangen, mit denen es arbeiten muss, und Parameter, die Informationen angeben, die verwendet werden, um die Merkmale des Vorgangs zu bestimmen. Ein Cmdlet kann beispielsweise über einen Parameter verfügen, der Daten aus der Pipeline empfängt, und das Cmdlet kann über einen Parameter verfügen, der angibt, dass das Cmdlet gezwungen werden kann, seinen Vorgang Name Force auszuführen. Es gibt keine Beschränkung für die Anzahl von Parametern, die ein Cmdlet definieren kann.

Verwenden von Standardparameternamen

Ihr Cmdlet sollte Standardparameternamen verwenden, damit der Benutzer schnell bestimmen kann, was ein bestimmter Parameter bedeutet. Wenn ein spezifischerer Name erforderlich ist, verwenden Sie einen Standardparameternamen, und geben Sie dann einen spezifischeren Namen als Alias an. Das Cmdlet verfügt beispielsweise über einen Parameter mit einem Get-Service generischen Namen ( Name ) und einem spezifischeren Alias ( ServiceName ). Beide Begriffe können verwendet werden, um den Parameter anzugeben.

Weitere Informationen zu Parameternamen und deren Datentypen finden Sie unter Cmdlet Parameter Name and Functionality Guidelines.

Verwenden von Singularparameternamen

Vermeiden Sie die Verwendung von Pluralnamen für Parameter, deren Wert ein einzelnes Element ist. Dies schließt Parameter ein, die Arrays oder Listen verwenden, da der Benutzer ein Array oder eine Liste mit nur einem Element angeben kann.

Pluralparameternamen sollten nur in Fällen verwendet werden, in denen der Wert des Parameters immer ein Wert mit mehreren Element ist. In diesen Fällen sollte das Cmdlet überprüfen, ob mehrere Elemente bereitgestellt werden, und das Cmdlet sollte dem Benutzer eine Warnung anzeigen, wenn nicht mehrere Elemente bereitgestellt werden.

Verwenden von Pascal Case für Parameternamen

Verwenden Sie pascal case für Parameternamen. Anders ausgedrückt: Schreiben Sie den ersten Buchstaben jedes Worts in den Parameternamen, einschließlich des ersten Buchstabens des Namens. Der Parametername verwendet ErrorAction z. B. die richtige Groß-/Groß-/Groß-/A.- Die folgenden Parameternamen verwenden falsche Groß-/Groß-/Groß-/Bildgröße:

errorAction
erroraction

Parameter, die eine Liste von Optionen verwenden

Es gibt zwei Möglichkeiten, einen Parameter zu erstellen, dessen Wert aus einer Reihe von Optionen ausgewählt werden kann.

Definieren Sie einen Enumerationstyp (oder verwenden Sie einen vorhandenen Enumerationstyp), der die gültigen Werte angibt. Verwenden Sie dann den Enumerationstyp , um einen Parameter dieses Typs zu erstellen.
Fügen Sie der Parameterdeklaration das ValidateSet-Attribut hinzu. Weitere Informationen zu diesem Attribut finden Sie unter ValidateSet-Attributdeklaration.

Verwenden von Standardtypen für Parameter

Verwenden Sie nach Möglichkeit Standardtypen für Parameter, um die Konsistenz mit anderen Cmdlets sicherzustellen. Weitere Informationen zu den Typen, die für verschiedene Parameter verwendet werden sollen, finden Sie unter Standard Cmdlet Parameter Names and Types. Dieses Thema enthält Links zu mehreren Themen, in denen die Namen und .NET Framework für Gruppen von Standardparametern beschrieben werden, z. B. die "Aktivitätsparameter".

Verwenden Strongly-Typed .NET Framework Typen

Parameter sollten als .NET Framework definiert werden, um eine bessere Parametervalidierung zu ermöglichen. Beispielsweise sollten Parameter, die auf einen Wert aus einem Satz von Werten beschränkt sind, als Enumerationstyp definiert werden. Um einen Uniform Resource Identifier (URI) zu unterstützen, definieren Sie den Parameter als System.Uri-Typ. Vermeiden Sie grundlegende Zeichenfolgenparameter für alle Freiformtexteigenschaften.

Verwenden konsistenter Parametertypen

Wenn derselbe Parameter von mehreren Cmdlets verwendet wird, verwenden Sie immer denselben Parametertyp. Wenn der Parameter beispielsweise ein System.Int16-Typ für ein Cmdlet ist, machen Sie den Parameter für ein anderes Cmdlet nicht als Process Process System.Uint16-Typ.

Parameter, die "true" und "false" verwenden

Wenn Ihr Parameter nur und true false akzeptiert, definieren Sie den Parameter als Typ System.Management.Automation.SwitchParameter. Ein switch-Parameter wird so true behandelt, als wäre er in einem Befehl angegeben. Wenn der -Parameter nicht in einem Befehl enthalten ist, Windows PowerShell den Wert des Parameters als false . Definieren Sie keine booleschen Parameter.

Wenn Ihr Parameter zwischen drei Werten unterscheiden muss: $true, $false und "unspecified", definieren Sie einen Parameter vom Typ Nullable <bool> . Die Notwendigkeit eines dritten, "nicht angegebenen" Werts tritt in der Regel auf, wenn das Cmdlet eine boolesche Eigenschaft eines Objekts ändern kann. In diesem Fall bedeutet "nicht angegeben", dass der aktuelle Wert der Eigenschaft nicht geändert wird.

Unterstützung von Arrays für Parameter

Häufig müssen Benutzer denselben Vorgang für mehrere Argumente ausführen. Für diese Benutzer sollte ein Cmdlet ein Array als Parametereingabe akzeptieren, damit ein Benutzer die Argumente als Windows PowerShell übergeben kann. Das Cmdlet Get-Process verwendet beispielsweise ein Array für die Zeichenfolgen, die die Namen der abzurufenden Prozesse identifizieren.

Unterstützen des PassThru-Parameters

Standardmäßig fungieren viele Cmdlets, die das System ändern, z. B. das Cmdlet Stop-Process, als "Senken" für Objekte und geben kein Ergebnis zurück. Diese Cmdlets sollten den PassThru -Parameter implementieren, um zu erzwingen, dass das Cmdlet ein Objekt zurückgibt. Wenn der Parameter angegeben wird, gibt das Cmdlet ein Objekt zurück, indem es die PassThru System.Management.Automation.Cmdlet.WriteObject-Methode aufruft. Beispielsweise beendet der folgende Befehl den Calc-Prozess und übergibt den resultierenden Prozess an die Pipeline.

Stop-Process calc -passthru

In den meisten Fällen sollten die Cmdlets "Add", "Set" und "New" einen Parameter PassThru unterstützen.

Supportparametersätze

Ein Cmdlet soll einen einzelnen Zweck erfüllen. Es gibt jedoch häufig mehr als eine Möglichkeit, den Vorgang oder das Vorgangsziel zu beschreiben. Beispielsweise kann ein Prozess anhand seines Namens, seines Bezeichners oder durch ein Prozessobjekt identifiziert werden. Das Cmdlet sollte alle angemessenen Darstellungen seiner Ziele unterstützen. Normalerweise erfüllt das Cmdlet diese Anforderung, indem es Parametersätze (als Parametersätze bezeichnet) angibt, die zusammen ausgeführt werden. Ein einzelner Parameter kann zu einer beliebigen Anzahl von Parametersätzen gehören. Weitere Informationen zu Parametersätzen finden Sie unter Cmdlet-Parametersätze.

Wenn Sie Parametersätze angeben, legen Sie nur einen Parameter im Satz auf ValueFromPipeline fest. Weitere Informationen zum Deklarieren des Parameter-Attributs finden Sie unter ParameterAttribute-Deklaration.

Wenn Parametersätze verwendet werden, wird der Standardparametersatz durch das Cmdlet-Attribut definiert. Der Standardparametersatz sollte die Parameter enthalten, die am wahrscheinlichsten in einer interaktiven Windows PowerShell werden. Weitere Informationen zum Deklarieren des Cmdlet-Attributs finden Sie unter CmdletAttribute-Deklaration.

Senden von Feedback an den Benutzer (SD04)

Verwenden Sie die Richtlinien in diesem Abschnitt, um dem Benutzer Feedback zu geben. Dieses Feedback ermöglicht es dem Benutzer, zu wissen, was im System geschieht, und bessere Administrative Entscheidungen zu treffen.

Mit Windows PowerShell Runtime kann ein Benutzer angeben, wie die Ausgabe jedes Aufrufs der -Methode behandelt werden soll, indem Write eine Einstellungsvariable festgelegt wird. Der Benutzer kann mehrere Einstellungsvariablen festlegen, darunter eine Variable, die bestimmt, ob das System Informationen anzeigen soll, und eine Variable, die bestimmt, ob das System den Benutzer abfragen soll, bevor weitere Maßnahmen ausgeführt werden.

Unterstützung der WriteWarning-, WriteVerbose- und WriteDebug-Methoden

Ein Cmdlet sollte die System.Management.Automation.Cmdlet.WriteWarning-Methode aufrufen, wenn das Cmdlet einen Vorgang ausführen möchte, der zu einem unbeabsichtigten Ergebnis führen kann. Beispielsweise sollte ein Cmdlet diese Methode aufrufen, wenn das Cmdlet eine schreibgeschützte Datei überschreiben möchte.

Ein Cmdlet sollte die System.Management.Automation.Cmdlet.WriteVerbose-Methode aufrufen, wenn der Benutzer details zur Vorgehensweise des Cmdlets benötigt. Ein Cmdlet sollte diese Informationen z. B. aufrufen, wenn der Cmdlet-Autor der Meinung ist, dass es Szenarien gibt, die möglicherweise weitere Informationen zur Funktionsweise des Cmdlets erfordern.

Das Cmdlet sollte die System.Management.Automation.Cmdlet.WriteDebug-Methode aufrufen, wenn ein Entwickler oder Produktsupporttechniker verstehen muss, was den Cmdlet-Vorgang beschädigt hat. Es ist nicht erforderlich, dass das Cmdlet die System.Management.Automation.Cmdlet.WriteDebug-Methode im gleichen Code aufruft, der die System.Management.Automation.Cmdlet.WriteVerbose-Methode aufruft, da der Debug Parameter beide Informationssätze darstellt.

Unterstützung von WriteProgress für Vorgänge, die viel Zeit in Anspruch nehmen

Cmdlet-Vorgänge, die lange dauern und nicht im Hintergrund ausgeführt werden können, sollten die Statusberichterstellung durch regelmäßige Aufrufe der System.Management.Automation.Cmdlet.WriteProgress-Methode unterstützen.

Verwenden der Hostschnittstellen

Gelegentlich muss ein Cmdlet direkt mit dem Benutzer kommunizieren, anstatt die verschiedenen Write- oder Should-Methoden zu verwenden, die von der System.Management.Automation.Cmdlet-Klasse unterstützt werden. In diesem Fall sollte das Cmdlet von der System.Management.Automation.PSCmdlet-Klasse abgeleitet werden und die System.Management.Automation.PSCmdlet.Host*-Eigenschaft verwenden. Diese Eigenschaft unterstützt verschiedene Ebenen des Kommunikationstyps, einschließlich der Typen PromptForChoice, Prompt und WriteLine/ReadLine. Auf der spezifischsten Ebene bietet sie auch Möglichkeiten zum Lesen und Schreiben einzelner Schlüssel und zum Umgang mit Puffern.

Sofern ein Cmdlet nicht speziell zum Generieren einer grafischen Benutzeroberfläche (GUI) entwickelt wurde, sollte es den Host nicht mithilfe der System.Management.Automation.PSCmdlet.Host*-Eigenschaft umgehen. Ein Beispiel für ein Cmdlet, das zum Generieren einer grafischen Benutzeroberfläche entwickelt wurde, ist das Out-GridView-Cmdlet.

Hinweis

Cmdlets sollten nicht die System.Console-API verwenden.

Erstellen einer Cmdlet-Hilfedatei (SD05)

Erstellen Sie für jede Cmdlet-Assembly eine Help.xml-Datei, die Informationen zum Cmdlet enthält. Diese Informationen umfassen eine Beschreibung des Cmdlets, Beschreibungen der Parameter des Cmdlets, Beispiele für die Verwendung des Cmdlets und vieles mehr.

Coderichtlinien

Die folgenden Richtlinien sollten beim Codieren von Cmdlets befolgt werden, um eine konsistente Benutzererfahrung zwischen der Verwendung Ihrer Cmdlets und anderen Cmdlets sicherzustellen. Wenn Sie eine Coderichtlinie finden, die für Ihre Situation gilt, sollten Sie sich die Entwurfsrichtlinien für ähnliche Richtlinien ansehen.

Codieren von Parametern (SC01)

Definieren Sie einen Parameter, indem Sie eine öffentliche Eigenschaft der Cmdlet-Klasse deklarieren, die mit dem Parameter-Attribut versehen ist. Parameter müssen keine statischen Member der abgeleiteten .NET Framework-Klasse für das Cmdlet sein. Weitere Informationen zum Deklarieren des Parameter-Attributs finden Sie unter Parameterattributdeklaration.

Unterstützung von Windows PowerShell Pfaden

Der Windows PowerShell Pfad ist der Mechanismus zum Normalisieren des Zugriffs auf Namespaces. Wenn Sie einem Parameter im Cmdlet einen Windows PowerShell Pfad zuweisen, kann der Benutzer ein benutzerdefiniertes Laufwerk definieren, das als Verknüpfung mit einem bestimmten Pfad fungiert. Wenn ein Benutzer ein solches Laufwerk bestimmt, können gespeicherte Daten, z. B. Daten in der Registrierung, konsistent verwendet werden.

Wenn ihr Cmdlet es dem Benutzer ermöglicht, eine Datei oder eine Datenquelle anzugeben, sollte es einen Parameter vom Typ System.Stringdefinieren. Wenn mehrere Laufwerke unterstützt werden, sollte der Typ ein Array sein. Der Name des Parameters sollte mit Path dem Alias PSPath sein. Darüber hinaus sollte der Path -Parameter Platzhalterzeichen unterstützen. Wenn keine Unterstützung für Platzhalterzeichen erforderlich ist, definieren Sie einen LiteralPath Parameter.

Wenn es sich bei den vom Cmdlet gelesenen oder geschriebenen Daten um eine Datei handelt, sollte das Cmdlet Windows PowerShell Pfadeingabe akzeptieren, und das Cmdlet sollte die System.Management.Automation.Sessionstate.Path-Eigenschaft verwenden, um die Windows PowerShell Pfade in Pfade zu übersetzen, die das Dateisystem erkennt. Die spezifischen Mechanismen umfassen die folgenden Methoden:

Wenn es sich bei den vom Cmdlet gelesenen oder geschriebenen Daten nur um einen Satz von Zeichenfolgen anstelle einer Datei handelt, sollte das Cmdlet die Anbieterinhaltsinformationen Content (Member) zum Lesen und Schreiben verwenden. Diese Informationen werden von der System.Management.Automation.Provider.CmdletProvider.InvokeProvider-Eigenschaft abgerufen. Diese Mechanismen ermöglichen es anderen Datenspeichern, am Lesen und Schreiben von Daten teilzunehmen.

Unterstützung von Platzhalterzeichen

Ein Cmdlet sollte nach Möglichkeit Platzhalterzeichen unterstützen. Platzhalterzeichen werden an vielen Stellen in einem Cmdlet unterstützt (insbesondere, wenn ein Parameter eine Zeichenfolge verwendet, um ein Objekt aus einer Gruppe von Objekten zu identifizieren). Das Stop-Proc Beispiel-Cmdlet aus dem StopProc-Tutorial definiert beispielsweise einen Parameter zum Behandeln von Name Zeichenfolgen, die Prozessnamen darstellen. Dieser Parameter unterstützt Platzhalterzeichen, sodass der Benutzer ganz einfach die prozesse angeben kann, die beendet werden sollen.

Wenn Unterstützung für Platzhalterzeichen verfügbar ist, erzeugt ein Cmdlet-Vorgang in der Regel ein Array. Gelegentlich ist es nicht sinnvoll, ein Array zu unterstützen, da der Benutzer möglicherweise nur ein einzelnes Element gleichzeitig verwendet. Beispielsweise muss das Cmdlet Set-Location kein Array unterstützen, da der Benutzer nur einen einzelnen Speicherort festlegt. In diesem Fall unterstützt das Cmdlet weiterhin Platzhalterzeichen, erzwingt jedoch die Auflösung an einem einzelnen Speicherort.

Weitere Informationen zu Platzhalterzeichenmustern finden Sie unter Unterstützen von Platzhalterzeichen in Cmdlet-Parametern.

Definieren von Objekten

Dieser Abschnitt enthält Richtlinien zum Definieren von Objekten für Cmdlets und zum Erweitern vorhandener Objekte.

Definieren von Standardmembern

Definieren Sie Standardmember, um einen Objekttyp in einer benutzerdefinierten Types.ps1xml-Datei zu erweitern (verwenden Sie die datei Windows PowerShell Types.ps1xml als Vorlage). Standardmember werden von einem Knoten mit dem Namen PSStandardMembers definiert. Mit diesen Definitionen können andere Cmdlets und die Windows PowerShell Runtime konsistent mit Ihrem Objekt arbeiten.

Definieren von ObjectMembers, die als Parameter verwendet werden sollen

Wenn Sie ein Objekt für ein Cmdlet entwerfen, stellen Sie sicher, dass dessen Member direkt den Parametern der Cmdlets zugeordnet sind, die es verwenden. Mit dieser Zuordnung kann das Objekt problemlos an die Pipeline gesendet und von einem Cmdlet an ein anderes übergeben werden.

Bereits vorhandene .NET Framework-Objekte, die von Cmdlets zurückgegeben werden, fehlen häufig einige wichtige oder praktische Member, die vom Skriptentwickler oder -benutzer benötigt werden. Diese fehlenden Member können besonders wichtig für die Anzeige und das Erstellen der richtigen Membernamen sein, damit das Objekt ordnungsgemäß an die Pipeline übergeben werden kann. Erstellen Sie eine benutzerdefinierte Datei Types.ps1xml, um diese erforderlichen Member zu dokumentieren. Beim Erstellen dieser Datei wird die folgende Namenskonvention empfohlen: <Your_Product_Name>. Types.ps1xml.

Beispielsweise können Sie Mode dem System.IO.FileInfo-Typ eine Skripteigenschaft hinzufügen, um die Attribute einer Datei eindeutiger anzuzeigen. Darüber hinaus können Sie Count dem System.Array-Typ eine Aliaseigenschaft hinzufügen, um die konsistente Verwendung dieses Eigenschaftsnamens (anstelle von ) zu Length ermöglichen.

Implementieren der IComparable-Schnittstelle

Implementieren Sie eine System.IComparable-Schnittstelle für alle Ausgabeobjekte. Dadurch können die Ausgabeobjekte problemlos an verschiedene Sortier- und Analyse-Cmdlets weitergeleitet werden.

Aktualisieren von Anzeigeinformationen

Wenn die Anzeige für ein Objekt nicht die erwarteten Ergebnisse liefert, erstellen Sie eine benutzerdefinierte <YourProductName> . Format.ps1xml-Datei für dieses Objekt.

Unterstützung von klar definierten Pipelineeingaben (SC02)

Implementieren für die Mitte einer Pipeline

Implementieren Sie ein Cmdlet unter der Annahme, dass es von der Mitte einer Pipeline aus aufgerufen wird (d.b. andere Cmdlets erzeugen die Eingabe oder nutzen die Ausgabe). Sie können beispielsweise davon ausgehen, dass das Get-Process Cmdlet, da es Daten generiert, nur als erstes Cmdlet in einer Pipeline verwendet wird. Da dieses Cmdlet jedoch für die Mitte einer Pipeline konzipiert ist, ermöglicht dieses Cmdlet vorherigen Cmdlets oder Daten in der Pipeline, die abzurufenden Prozesse anzugeben.

Unterstützung von Eingaben aus der Pipeline

Schließen Sie in jedem Parametersatz für ein Cmdlet mindestens einen Parameter ein, der Eingaben aus der Pipeline unterstützt. Die Unterstützung für Pipelineeingaben ermöglicht es dem Benutzer, Daten oder Objekte abzurufen, sie an den richtigen Parametersatz zu senden und die Ergebnisse direkt an ein Cmdlet zu übergeben.

Ein Parameter akzeptiert Eingaben aus der Pipeline, wenn das Parameter-Attribut das ValueFromPipeline Schlüsselwort, das ValueFromPipelineByPropertyName Schlüsselwortattribut oder beide Schlüsselwörter in seiner Deklaration enthält. Wenn keiner der Parameter in einem Parametersatz die ValueFromPipeline Schlüsselwörter oder ValueFromPipelineByPropertyName unterstützt, kann das Cmdlet nicht sinnvoll nach einem anderen Cmdlet platziert werden, da es Pipelineeingaben ignoriert.

Unterstützung der ProcessRecord-Methode

Um alle Datensätze aus dem vorherigen Cmdlet in der Pipeline zu akzeptieren, muss Ihr Cmdlet die System.Management.Automation.Cmdlet.ProcessRecord-Methode implementieren. Windows PowerShell ruft diese Methode mehrmals auf, einmal für jeden Datensatz, der an Ihr Cmdlet gesendet wird.

Schreiben einzelner Datensätze in die Pipeline (SC03)

Wenn ein Cmdlet -Objekte zurückgibt, sollte das Cmdlet die Objekte sofort beim Generieren schreiben. Das Cmdlet sollte sie nicht speichern, um sie in einem kombinierten Array zu puffern. Die Cmdlets, die die Objekte als Eingabe empfangen, können die Ausgabeobjekte dann ohne Verzögerung verarbeiten, anzeigen oder verarbeiten und anzeigen. Ein Cmdlet, das Ausgabeobjekte nacheinander generiert, sollte die System.Management.Automation.Cmdlet.WriteObject-Methode aufrufen. Ein Cmdlet, das Ausgabeobjekte in Batches generiert (z. B. weil eine zugrunde liegende API ein Array von Ausgabeobjekten zurückgibt), sollte die System.Management.Automation.Cmdlet.WriteObject-Methode aufrufen, wobei der zweite Parameter auf festgelegt true ist.

Erstellen von Cmdlets Case-Insensitive und Case-Preserving (SC04)

Standardmäßig wird bei Windows PowerShell selbst die Groß-/Kleinschreibung nicht beachtet. Da es sich jedoch um viele bereits vorhandene Systeme handelt, behält Windows PowerShell die Case-Funktion bei, um den Betrieb zu vereinfachen und die Kompatibilität zu gewährleisten. Anders ausgedrückt: Wenn ein Zeichen in Großbuchstaben angegeben wird, behält Windows PowerShell es in Großbuchstaben bei. Damit Systeme gut funktionieren, muss ein Cmdlet diese Konvention befolgen. Wenn möglich, sollte die Groß-/Kleinschreibung nicht beachtet werden. Sie sollte jedoch den ursprünglichen Fall für Cmdlets beibehalten, die später in einem Befehl oder in der Pipeline auftreten.

Siehe auch

Erforderliche Entwicklungsrichtlinien

Empfohlene Entwicklungsrichtlinien

Schreiben eines Windows PowerShell-Cmdlets