-
Notifications
You must be signed in to change notification settings - Fork 37
Coding Standards
For all contributors and future contributors to PoshSec, We ask that you follow this guide when writing your scripts/modules.
-
Avoid Write-Host at all costs. You should output custom objects instead. Please read:
-
If you want to display relevant debugging information to the screen, use Write-Verbose. The user can always just tack on '-Verbose'.
-
Always provide descriptive, comment-based help for every script. Also, be sure to include your name and a BSD 3-Clause license.
-
Make sure all functions follow the proper PowerShell verb-noun agreement. Use Get-Verb to list the default verbs used by PowerShell.
-
We prefer that variable names be capitalized and be as descriptive as possible.
-
Provide logical spacing in between your code. Indent your code to make it more readable.
-
If you find yourself repeating code, write a function.
-
Catch all anticipated errors and provide meaningful output. If you have an error that should stop execution of the script, use 'Throw'. If you have an error that doesn't need to stop execution, use Write-Error.
-
Do not use hardcoded paths. A script should be useable right out of the box. No one should have to modify the code unless they want to.
-
Use positional parameters and make parameters mandatory when it makes sense to do so. For example, I'm looking for something like the following:
[Parameter(Position = 0, Mandatory = $True)]
-
Don't use any aliases unless it makes sense for receiving pipeline input. They make code more difficult to read for people who are unfamiliar with a particular alias.
-
Don't let commands run on for too long. For example, a pipeline is a natural place for a line break.
-
Don't go overboard with inline comments. Only use them when certain aspects of the code might be confusing to a reader.
-
Use Out-Null to suppress unwanted/irrelevant output.
-
Use the Write-Output keyword when returning an object from a function. I know it's not necessary but it makes the code more readable.
-
Use default values for your parameters when it makes sense. Ideally, you want a script that will work without requiring any parameters.
-
Scripts that are intended to run on a remote machine should be self-contained and not rely upon any additional scripts. Scripts that are designed to run on your host machine can have dependencies on other scripts.
-
If a script creates complex custom objects, include a ps1xml file that will properly format the object's output.
Current Release Version: 1.0 - www.poshsec.com - team@poshsec.com - @PoshSec