Skip to content

📖 [Docs]: OutputType parameter set scoping and parameter set naming rules strengthened#66

Merged
Marius Storhaug (MariusStorhaug) merged 2 commits into
mainfrom
feat-outputtype-parameterset-naming
Jul 25, 2026
Merged

📖 [Docs]: OutputType parameter set scoping and parameter set naming rules strengthened#66
Marius Storhaug (MariusStorhaug) merged 2 commits into
mainfrom
feat-outputtype-parameterset-naming

Conversation

@MariusStorhaug

Copy link
Copy Markdown
Member

PowerShell coding standards now precisely cover two tightly coupled topics: how to scope [OutputType] when parameter sets return different types, and what makes a parameter set name acceptable.

New: [OutputType] scoping per parameter set

A new subsection "[OutputType] and parameter sets" is added directly after the Section structure code example. It explains when to use a single unscoped [OutputType] (all sets return the same type) versus per-set scoping using ParameterSetName, includes a runnable snippet showing both [OutputType] attributes alongside [CmdletBinding(DefaultParameterSetName = ...)], and states the contract: types in [OutputType] must match .OUTPUTS in comment-based help.

Changed: Parameter set naming rule

The previous bullet ("Name every parameter set with an intent-revealing name … never Default or __AllParameterSets") has been replaced with a precise rule that explains why: parameter set names appear verbatim in Get-Help syntax output and are read by callers, not just developers. The rule now lists the acceptable patterns (ByName, ByPath, ByLiteralPath, ByGuid, WithCredential, AsComputerName, AsSession), enumerates explicitly unacceptable names (Default, __AllParameterSets, __DefaultParameterSet, ParameterSetA, Set1, Mode1), and makes DefaultParameterSetName mandatory when multiple sets exist.

Technical Details

  • Single file changed: src/docs/Coding-Standards/PowerShell/Functions.md
  • +20 lines, −1 line; no surrounding context altered.
  • Both changes shipped in one commit because [OutputType] scoping is meaningless without well-named parameter sets to reference.
Related issues

…ing rules

- Add '[OutputType] and parameter sets' subsection after the Section structure code
  example, covering single-type (no scoping) vs per-set scoping with a concrete
  powershell snippet and the OutputType/.OUTPUTS contract rule.
- Replace the weak parameter set naming bullet with a full rule: names appear verbatim
  in Get-Help syntax output, must be readable English phrases (ByName, ByPath,
  WithCredential, AsSession style), lists explicitly unacceptable names, and mandates
  DefaultParameterSetName when multiple sets exist.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Update the [OutputType] code example to use 'By display name' and
'From file path' instead of 'ByName'/'ByPath', demonstrating that
PowerShell parameter set names support spaces and read more naturally
in Get-Help output that way.

Strengthen the naming rule bullet to lead with spaced prose names as
the preferred form ('By display name', 'From file path', 'As computer
name') and note explicitly that spaces are supported and encouraged.
PascalCase single-word names remain acceptable as a fallback.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
@MariusStorhaug
Marius Storhaug (MariusStorhaug) marked this pull request as ready for review July 25, 2026 12:51
@MariusStorhaug
Marius Storhaug (MariusStorhaug) merged commit 2460664 into main Jul 25, 2026
19 checks passed
@MariusStorhaug
Marius Storhaug (MariusStorhaug) deleted the feat-outputtype-parameterset-naming branch July 25, 2026 12:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant