-
Notifications
You must be signed in to change notification settings - Fork 5
Open
Description
Summary of the new feature / enhancement
We are improving our undocumented code standard as we go, which creates difficulties for new contributors.
To solve this issue we need to document our code, and test for it this standard to ensure our production code is up to standard and new PR's will adhere to the same standard.
Documentation
For all Functions we require:
- Help not to be auto-generated (contain entries like
[CommonParameters]
- Description (what does this function do)
- Example code + Description
- A valid Help Link if entered
For each parameter of each Function:
- A description for the parameter (what does this parameter represent)
Required
value in Help should match IsMandatory property of parameterParameter type in help should match code
- Documentation should contain all the parameters in the code and vice versa
The module manifest:
- Should be valid structure-wise
- Contain a valid modulename
- Contain a valid root module
- Contain a valid version, and not be empty
- Contain a valid description, and not be empty
- Contain a valid author, and not be empty
- Contain a valid GUID
- Have a copyright
Files formatting
- No text file should use Unicode/UTF-16 encoding, just UTF-8
- No Tab characters should be used within files [`t]. These should be space characters
Functionality
For each function:
- All flows should be tested
- All cases of if/else statements
- Loop constructs
- WhatIf output, Confirm behavior
- Force Behavior (if applicable)
- Should implement process script-blocks to facilitate pipeline processing
For each parameter in a function:
- All input methods should be tested
- Regular input (inline or via splatting)
- ValueFromPipelineByPropertyName
- ValueFromPipeline
- Should have an implementation in the function, or be removed
Error handling:
- All potentially failing actions should be enclosed in try/catch
- All try/catch should use Statement-errors, except when it's breaking for the script, then it should implement throw
All scripts should log to the users and developers:
- Errors:
- Functions should log errors when something fails to be done without breaking processing for other items
- Warning:
- Functions should log warnings when you want to warn users about executions with unexpected results/side-effects of actions without the action breaking processing.
- Verbose
- Functions should log verbose messages about which actions are about to be taken before processing occurs (which item is being processed, what non-native function is being called, when a certain condition is applicable)
- Debug
- Functions should log Debug to inform developers why certain actions are taken (if statement conditions, arguments to other functions etc.)
Style
For style in our module's functions we adhere to the Default PSScriptAnalyzer ruleset, supplemented by Chris Dent his module (https://github.com/indented-automation/Indented.ScriptAnalyzerRules)
Proposed technical implementation details (optional)
No response
Metadata
Metadata
Assignees
Labels
No labels