Do And Do Not

Writing Documentation:

• If a a function accepts pipeline input, there should at least be one example that shows it being used that way.

• In Examples, we need to ensure that no unneeded quotes in parameter values and discourage useless quotes.

Writing Code:

• Prefer dot notation over Select -ExpandProperty.

  • eg. (Get-ChildItem).FullName

• Try to return a useful object for the use case and dont try to overtly customize standard .NET types unless needed.

• When supressing output using null types, use chained assignment.

  • eg. $null = $result = Command-WhichProducedOutputWhenAssigned

• Avoid Write-Output, instead return useful objects closest to the value type of the target

• If you need to initialize a value, use $null and avoid values such as a blank string

• Semicolons are discouraged unless absolutely necessary, consider breaking your statements on multiple lines:

  • eg. Constructing a pscustomobject from a hash table, also useful for cheap object creation:

    [pscustomobject]@{
        ServerName = $servername
        IsEnabled = $true
    }
    

• For encapsulating input please use double quotes in PowerShell any output should have bracket escaped values.

• Avoid continuation marks (backticks) in code if at all possible.

• Do not indent BEGIN, PROCESS, or END in advanced functions.

• Casing follows PowerShell community recommendations:

  • Lower:

    • Language keyword (try, catch, foreach)
    • Process block keyword (begin, process, end)

  • Pascal:

    • Comment help keywords (.Example, .Synopsis)
    • Package or modules
    • Class
    • Exception
    • Global variables

  • Camel Case:

    • Local variables ($localArgument)

  • There may be rare cases in which features do not work without required casing, in those cases ignore these recommendations.

• When choosing names and methods for booleans, consider using a more descriptive name than "Enabled" or "IsEnabled", instead add additional descriptive information such as "IsAdEnabled" or "IsSqlEnabled"

• The defacto naming convention for any command is ApprovedVerb-D365*

• Use one space after a bracket.

• Use -Force instead of -Confirm:$False

• Open braces on the same line, Closing braces always on their own line.

• There is no need to write empty keywords in advanced functions if they are not used (begin,process,end)

Note: This entire page is deeply inspired by the work done over in the dbatool.io module. Pay them a visit and learn from the very same people as we did.