foreach
and dynamicparam
), as well as operators such as -eq
and -match
. The keywords in comment-based help are written in UPPERCASE to make it easy to spot them among the dense prose of documentation.Verb-Noun
naming conventions, using PascalCase within both Verb and Noun.$PSBoundParameters
or the command Get-PSDrive
. Note that (as specified in the .NET guidelines) this does not affect the commonly capitalized (but not acronym) words "OK" and "ID" . You should also not extend it to compound acronyms, such as when Azure's Resource Manager (RM) meets a Virtual Machine (VM) in Start-AzureRmVM
...We are aware that there are many places where these conventions have not been followed properly for various reasons -- you should consider these exceptions (such as for COM interop) or mistakes (such asSystem.Data.SqlClient.SQLDebugging
), but not a reason for you to disregard the conventions.
$Script:PSBoundParameters
or $Global:DebugPreference
. If you are using camelCase for a variable that starts with a two-letter acronym (where both letters are capitalized), both letters should be set to lowercase (such as adComputer
).ForEach-Object
and Where-Object
) are common, and an inherent part of the syntax of important PowerShell-based domain-specific languages such as DSC. Since it's required to place the opening brace on the end of the line in those cases, the only consistent option is to follow OTBS.begin
block), add parameters and necessary validation and so on, but you should avoid writing scripts or functions without [CmdletBinding()]
, and you should always at least consider making it take pipeline input.end
block (and even has a filter
keyword that converts the anonymous block to a process
block), we recommend against using these features as it results in less explicit code.[Tab]
key to indent, but most editors can be configured to insert spaces instead of actual tab characters. For most programming languages and editors (including PowerShell ISE) the default is four spaces, and that's what we recommend. Different teams and projects may have different standards, and when contributing to a project, you should abide by the predominant style, of course.>>>
and thus limits your line length to 116 anyway.$( ... )
and scriptblocks { ... }
should have a single space on the inside of the braces or parentheses to improve readability by making code blocks stand out -- and to further distinguish scriptblocks from variable delimiter braces ${...}
;
) as Line Terminators