Skip to content

Document standards on code #46

@Manbearpiet

Description

@Manbearpiet

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 parameter
  • Parameter 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

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions