Los documentos en la respuesta de @ oɔɯǝɹ son una buena fuente, aunque algo tangencial.
Si usa Visual Studio Code, que está planeado para reemplazar el antiguo ISE de PowerShell, y luego instala la extensión VS Code PowerShell , que incluye varias opciones de formato que se basaron al menos parcialmente en la Guía de mejores prácticas y estilo no oficiales de PowerShell . Microsoft administra tanto el código VS como la extensión PowerShell, por lo que es tan oficial como una guía no oficial.
No estoy de acuerdo con todo lo que dicen. Por ejemplo, vengo de PHP, Java, C # y SQL, donde se esperan puntos y comas si no se requieren. El código me parece mal sin ellos, así que los incluyo. Si hubiera un #requires SemicolonTerminator, lo habilitaría en la mayoría de mis scripts para no tener que preocuparme de que el espacio en blanco rompa una línea. Odio escapar de los retornos de carro y otros VB-ismos.
El resto de estos son mi opinión:
¿Usar el nombre o alias del cmdlet real?
Sé inequívoco. Nunca use un alias en un guión guardado; incluso un alias predeterminado. No hay nada que impida a un usuario cambiar los alias predeterminados. Es más seguro asumir que no son inmutables.
Especifique el nombre del parámetro del cmdlet completo o solo parcialmente (dir -Recurse versus dir -r)
Nuevamente, sea inequívoco. Los nombres completos de los parámetros tienen la mejor compatibilidad hacia adelante. -rpuede ser inequívoco hoy, pero no hay nada que impida que las futuras versiones de un comando introduzcan nuevos parámetros. Vas a usar un IDE (ya sea ISE o VS Code). Presiona Ctrl+ Spacey completa automáticamente ese parámetro.
Tenga en cuenta que ls -r es ambiguo. -ReadOnlyEs otro parámetro de Get-ChildItem.
Al especificar argumentos de cadena para cmdlets, los encierra entre comillas (New-Object 'System.Int32' versus New-Object System.Int32
En general, las comillas solo deben usarse cuando sea necesario (p New-Object -TypeName 'System.Collections.Generic.HashSet[System.Int32]'. Ej . , Use comillas simples cuando pueda, y solo comillas dobles cuando necesite encapsular comillas simples o incrustar variables.
Al escribir funciones y filtros, ¿especifica los tipos de parámetros?
Normalmente lo hago, a menos que necesite aceptar específicamente una amplia variedad de tipos con el mismo parámetro y no quiera escribir conjuntos de parámetros individuales.
¿Escribes cmdlets en el caso correcto (oficial)?
Estuche Pascal. Si.
Para palabras clave como BEGIN ... PROCESS ... END, ¿las escribe solo en mayúsculas?
He visto declaraciones, operadores y construcciones del lenguaje como Begin, If, ForEach, -NotIn, así como begin, if, foreach, -notin. Personalmente, prefiero las minúsculas y dejo los comandos como Pascal, pero ambos son igualmente comunes.
Otros:
Siempre especifique los parámetros. No confíe en el orden posicional. New-Object -TypeName System.Int32terminado New-Object System.Int32. No sé si eso se acordó, pero, una vez más, parece apoyar la idea general de "no ser ambiguo".
Si estoy escribiendo un módulo, uso verbos estándar indicados por Get-Verb. Sin embargo, esta lista es extremadamente estrecha, por lo que los nombres de script independientes para scripts que solo yo mismo ejecutaré a menudo no lo hacen. El problema con la lista de verbos genéricos es que tiende hacia dentro Get-ScriptForSpecificPurposeNoNotThatOneTheOtherOne.ps1. Si estoy escribiendo un script que extrae ciertas páginas de un archivo PDF, no lo estoy llamando Get-ExtractedAccountPDFPages.ps1. Lo estoy llamando Extract-AccountPDFPages.ps1. No me preocupa la capacidad de detección de un script que se ejecuta como un programa en sí mismo y no pretende ser modular por su propia naturaleza.
Rompe las reglas cuando sea más legible, más concreto o más fácil de mantener.