diff --git a/docs/Rules/AlignAssignmentStatement.md b/docs/Rules/AlignAssignmentStatement.md index 28ca9f47f..573b54b68 100644 --- a/docs/Rules/AlignAssignmentStatement.md +++ b/docs/Rules/AlignAssignmentStatement.md @@ -1,6 +1,6 @@ --- description: Align assignment statement -ms.date: 06/28/2023 +ms.date: 03/20/2026 ms.topic: reference title: AlignAssignmentStatement --- @@ -10,14 +10,13 @@ title: AlignAssignmentStatement ## Description -Consecutive assignment statements are more readable when they're aligned. -Assignments are considered aligned when their `equals` signs line up vertically. +Consecutive assignment statements are more readable when they're aligned. Assignments are considered +aligned when their `equals` signs line up vertically. -This rule looks at the key-value pairs in hashtables (including DSC -configurations) as well as enum definitions. +This rule looks at the key-value pairs in hashtables (including DSC configurations) as well as enum +definitions. -Consider the following example which has a hashtable and enum which are not -aligned. +Consider the following example with a hashtable and enum that isn't aligned. ```powershell $hashtable = @{ @@ -45,8 +44,8 @@ enum Enum { } ``` -The rule ignores any assignments within hashtables and enums which are on the -same line as others. For example, the rule ignores `$h = @{a = 1; b = 2}`. +The rule ignores any assignments within hashtables and enums which are on the same line as others. +For example, the rule ignores `$h = @{a = 1; b = 2}`. ## Configuration @@ -71,15 +70,14 @@ Enable or disable the rule during ScriptAnalyzer invocation. #### CheckHashtable: bool (Default value is `$true`) -Enforce alignment of assignment statements in a hashtable and in a DSC -Configuration. There is only one setting for hashtable and DSC configuration -because the property value pairs in a DSC configuration are parsed as key-value -pairs of a hashtable. +Enforce alignment of assignment statements in a hashtable and in a DSC Configuration. There is only +one setting for hashtable and DSC configuration because the property value pairs in a DSC +configuration are parsed as key-value pairs of a hashtable. #### AlignHashtableKvpWithInterveningComment: bool (Default value is `$true`) -Include key-value pairs in the alignment that have an intervening comment - that -is to say a comment between the key name and the equals sign. +Include key-value pairs in the alignment that have an intervening comment - that is to say a comment +between the key name and the equals sign. Consider the following: @@ -91,8 +89,7 @@ $hashtable = @{ } ``` -With this setting disabled, the line with the comment is ignored, and it would -be aligned like so: +With this setting disabled, the line with the comment is ignored, and it would be aligned like so: ```powershell $hashtable = @{ @@ -118,8 +115,8 @@ Enforce alignment of assignment statements of an Enum definition. #### AlignEnumMemberWithInterveningComment: bool (Default value is `$true`) -Include enum members in the alignment that have an intervening comment - that -is to say a comment between the member name and the equals sign. +Include enum members in the alignment that have an intervening comment - that is to say a comment +between the member name and the equals sign. Consider the following: @@ -131,8 +128,7 @@ enum Enum { } ``` -With this setting disabled, the line with the comment is ignored, and it would -be aligned like so: +With this setting disabled, the line with the comment is ignored, and it would be aligned like so: ```powershell enum Enum { @@ -154,9 +150,8 @@ enum Enum { #### IncludeValuelessEnumMembers: bool (Default value is `$true`) -Include enum members in the alignment that don't have an initial value - that -is to say they don't have an equals sign. Enum's don't need to be given a value -when they're defined. +Include enum members in the alignment that don't have an explicitly assigned value. Enums don't +need to be given a value when they're defined. Consider the following: @@ -168,8 +163,8 @@ enum Enum { } ``` -With this setting disabled the third line which has no value is not considered -when choosing where to align assignments. It would be aligned like so: +With this setting disabled, the third line, which has no value, isn't considered when choosing where +to align assignments. It would be aligned like so: ```powershell enum Enum { @@ -179,8 +174,7 @@ enum Enum { } ``` -With it enabled, the valueless member is included in alignment as if it had a -value: +With it enabled, the valueless member is included in alignment as if it had a value: ```powershell enum Enum { diff --git a/docs/Rules/AvoidLongLines.md b/docs/Rules/AvoidLongLines.md index c36daaa86..89474c8b8 100644 --- a/docs/Rules/AvoidLongLines.md +++ b/docs/Rules/AvoidLongLines.md @@ -1,6 +1,6 @@ --- description: Avoid long lines -ms.date: 04/29/2025 +ms.date: 03/20/2026 ms.topic: reference title: AvoidLongLines --- @@ -10,8 +10,8 @@ title: AvoidLongLines ## Description -The length of lines, including leading spaces (indentation), should be less than the configured number -of characters. The default length is 120 characters. +The length of lines, including leading spaces (indentation), should be less than the configured +number of characters. The default length is 120 characters. > [!NOTE] > This rule isn't enabled by default. The user needs to enable it through settings. diff --git a/docs/Rules/README.md b/docs/Rules/README.md index 5df834708..fca031e33 100644 --- a/docs/Rules/README.md +++ b/docs/Rules/README.md @@ -1,6 +1,6 @@ --- description: List of PSScriptAnalyzer rules -ms.date: 03/27/2024 +ms.date: 03/20/2026 ms.topic: reference title: List of PSScriptAnalyzer rules --- diff --git a/docs/Rules/UseConsistentParameterSetName.md b/docs/Rules/UseConsistentParameterSetName.md index 5ad33eb22..6e9a4598f 100644 --- a/docs/Rules/UseConsistentParameterSetName.md +++ b/docs/Rules/UseConsistentParameterSetName.md @@ -1,6 +1,6 @@ --- description: Use consistent parameter set names and proper parameter set configuration. -ms.date: 08/19/2025 +ms.date: 03/20/2026 ms.topic: reference title: UseConsistentParameterSetName --- @@ -11,18 +11,25 @@ title: UseConsistentParameterSetName ## Description -Parameter set names in PowerShell are case-sensitive, unlike most other PowerShell elements. This rule ensures consistent casing and proper configuration of parameter sets to avoid runtime errors and improve code clarity. +Parameter set names in PowerShell are case-sensitive, unlike most other PowerShell elements. This +rule ensures consistent casing and proper configuration of parameter sets to avoid runtime errors +and improve code clarity. The rule performs five different checks: -1. **Missing DefaultParameterSetName** - Warns when parameter sets are used but no default is specified -2. **Multiple parameter declarations** - Detects when a parameter is declared multiple times in the same parameter set. This is ultimately a runtime exception - this check helps catch it sooner. -3. **Case mismatch between DefaultParameterSetName and ParameterSetName** - Ensures consistent casing -4. **Case mismatch between different ParameterSetName values** - Ensures all references to the same parameter set use identical casing -5. **Parameter set names containing newlines** - Warns against using newline characters in parameter set names +1. **Missing DefaultParameterSetName** - Warns when parameter sets are used but no default is + specified +1. **Multiple parameter declarations** - Detects when a parameter is declared multiple times in the + same parameter set. This is ultimately a runtime exception - this check helps catch it sooner. +1. **Case mismatch between DefaultParameterSetName and ParameterSetName** - Ensures consistent + casing +1. **Case mismatch between different ParameterSetName values** - Ensures all references to the same + parameter set use identical casing +1. **Parameter set names containing newlines** - Warns against using newline characters in parameter + set names > [!NOTE] -> This rule is not enabled by default. The user needs to enable it through settings. +> This rule isn't enabled by default. The user needs to enable it through settings. ## How @@ -43,7 +50,7 @@ function Get-Data { param( [Parameter(ParameterSetName='ByName')] [string]$Name, - + [Parameter(ParameterSetName='ByID')] [int]$ID ) @@ -55,7 +62,7 @@ function Get-Data { param( [Parameter(ParameterSetName='byname')] [string]$Name, - + [Parameter(ParameterSetName='ByID')] [int]$ID ) @@ -67,7 +74,7 @@ function Get-Data { param( [Parameter(ParameterSetName='ByName')] [string]$Name, - + [Parameter(ParameterSetName='byname')] [string]$DisplayName ) @@ -100,11 +107,11 @@ function Get-Data { param( [Parameter(ParameterSetName='ByName', Mandatory)] [string]$Name, - + [Parameter(ParameterSetName='ByName')] [Parameter(ParameterSetName='ByID')] [string]$ComputerName, - + [Parameter(ParameterSetName='ByID', Mandatory)] [int]$ID ) @@ -129,7 +136,9 @@ Rules = @{ ## Notes -- Parameter set names are case-sensitive in PowerShell, making this different from most other PowerShell elements +- Parameter set names are case-sensitive in PowerShell, making this different from most other + PowerShell elements - The first occurrence of a parameter set name in your code is treated as the canonical casing -- Parameters without [Parameter()] attributes are automatically part of all parameter sets -- It's a PowerShell best practice to always specify a DefaultParameterSetName when using parameter sets \ No newline at end of file +- Parameters without `[Parameter()]` attributes are automatically part of all parameter sets +- It's a PowerShell best practice to always specify a `DefaultParameterSetName` when using parameter + sets \ No newline at end of file diff --git a/docs/Rules/UseConsistentParametersKind.md b/docs/Rules/UseConsistentParametersKind.md index 04a323b3d..20a470f30 100644 --- a/docs/Rules/UseConsistentParametersKind.md +++ b/docs/Rules/UseConsistentParametersKind.md @@ -1,26 +1,36 @@ +--- +description: Use the same pattern when defining parameters. +ms.date: 03/20/2026 +ms.topic: reference +title: UseConsistentParametersKind +--- # UseConsistentParametersKind **Severity Level: Warning** ## Description -All functions should have same parameters definition kind specified in the rule. -Possible kinds are: -1. `Inline`, i.e.: -```PowerShell -function f([Parameter()]$FirstParam) { - return -} -``` -2. `ParamBlock`, i.e.: -```PowerShell -function f { - param([Parameter()]$FirstParam) - return -} -``` +All functions should use the same pattern when defining parameters. Possible pattern types are: -* For information: in simple scenarios both function definitions above may be considered as equal. Using this rule as-is is more for consistent code-style than functional, but it can be useful in combination with other rules. +1. `Inline` + + ```powershell + function f([Parameter()]$FirstParam) { + return + } + ``` + +1. `ParamBlock` + + ```powershell + function f { + param([Parameter()]$FirstParam) + return + } + ``` + +In simple scenarios, both function definitions shown are considered to be equal. The purpose of this +rule is to enforce consistent code style across the codebase. ## How to Fix @@ -28,8 +38,9 @@ Rewrite function so it defines parameters as specified in the rule ## Example -### When the rule sets parameters definition kind to 'Inline': -```PowerShell +When the rule sets parameters definition kind to `Inline`: + +```powershell # Correct function f([Parameter()]$FirstParam) { return @@ -42,9 +53,10 @@ function g { } ``` -### When the rule sets parameters definition kind to 'ParamBlock': -```PowerShell -# Inorrect +When the rule sets parameters definition kind to `ParamBlock`: + +```powershell +# Incorrect function f([Parameter()]$FirstParam) { return } diff --git a/docs/Rules/UseConstrainedLanguageMode.md b/docs/Rules/UseConstrainedLanguageMode.md index 50ccfd0e2..e12476531 100644 --- a/docs/Rules/UseConstrainedLanguageMode.md +++ b/docs/Rules/UseConstrainedLanguageMode.md @@ -1,6 +1,6 @@ --- description: Use patterns compatible with Constrained Language Mode -ms.date: 03/17/2026 +ms.date: 03/20/2026 ms.topic: reference title: UseConstrainedLanguageMode --- @@ -10,22 +10,31 @@ title: UseConstrainedLanguageMode ## Description -This rule identifies PowerShell patterns that are restricted or not permitted in Constrained Language Mode (CLM). +This rule identifies PowerShell patterns that are restricted or not permitted in Constrained +Language Mode (CLM). Constrained Language Mode is a PowerShell security feature that restricts: + - .NET types that can be used - COM objects that can be instantiated - Commands that can be executed - Language features that can be used CLM is commonly used in: + - Application Control environments (Application Control for Business, AppLocker) - Just Enough Administration (JEA) endpoints - Secure environments requiring additional PowerShell restrictions -**Signed Script Behavior**: Digitally signed scripts from trusted publishers execute in Full Language Mode (FLM) even in CLM environments. The rule detects signature blocks (`# SIG # Begin signature block`) and adjusts checks accordingly - most restrictions don't apply to signed scripts, but certain checks (dot-sourcing, parameter types, manifest best practices) are always enforced. +Digitally signed scripts from trusted publishers execute in Full Language Mode (FLM) even in CLM +environments. The rule detects signature blocks (`# SIG # Begin signature block`) and adjusts checks +accordingly. Most restrictions don't apply to signed scripts, but certain checks (dot-sourcing, +parameter types, manifest best practices) are always enforced. -**Important**: The rule performs a simple text check for signature blocks and does NOT validate signature authenticity or certificate trust. Actual signature validation is performed by PowerShell at runtime. +> [!IMPORTANT] +> The rule performs a simple text check for signature blocks and does NOT validate signature +> authenticity or certificate trust. Actual signature validation is performed by PowerShell at +> runtime. ## Constrained Language Mode Restrictions @@ -34,24 +43,26 @@ CLM is commonly used in: The following are flagged for unsigned scripts: 1. **Add-Type** - Code compilation not permitted -2. **Disallowed COM Objects** - Only Scripting.Dictionary, Scripting.FileSystemObject, VBScript.RegExp allowed -3. **Disallowed .NET Types** - Only ~70 allowed types (string, int, hashtable, pscredential, etc.) -4. **Type Constraints** - On parameters and variables -5. **Type Expressions** - Static type references like `[Type]::Method()` -6. **Type Casts** - Converting to disallowed types -7. **Member Invocations** - Methods/properties on disallowed types -8. **PowerShell Classes** - `class` keyword not permitted -9. **XAML/WPF** - Not permitted -10. **Invoke-Expression** - Restricted -11. **Dot-Sourcing** - May be restricted depending on the file being sourced -12. **Module Manifest Wildcards** - Wildcard exports not recommended -13. **Module Manifest .ps1 Files** - Script modules ending with .ps1 not allowed +1. **Disallowed COM Objects** - Only Scripting.Dictionary, Scripting.FileSystemObject, + VBScript.RegExp allowed +1. **Disallowed .NET Types** - Only ~70 allowed types (string, int, hashtable, pscredential, etc.) +1. **Type Constraints** - On parameters and variables +1. **Type Expressions** - Static type references like `[Type]::Method()` +1. **Type Casts** - Converting to disallowed types +1. **Member Invocations** - Methods/properties on disallowed types +1. **PowerShell Classes** - `class` keyword not permitted +1. **XAML/WPF** - Not permitted +1. **Invoke-Expression** - Restricted +1. **Dot-Sourcing** - May be restricted depending on the file being sourced +1. **Module Manifest Wildcards** - Wildcard exports not recommended +1. **Module Manifest .ps1 Files** - Script modules ending with .ps1 not allowed Always enforced, even for signed scripts ### Signed Scripts (Selective Checking) For scripts with signature blocks, only these are checked: + - Dot-sourcing - Parameter type constraints - Module manifest wildcards (.psd1 files) @@ -75,14 +86,17 @@ For scripts with signature blocks, only these are checked: #### Enable: bool (Default value is `$false`) -Enable or disable the rule during ScriptAnalyzer invocation. This rule is disabled by default because not all scripts need CLM compatibility. +Enable or disable the rule during ScriptAnalyzer invocation. This rule is disabled by default +because not all scripts need CLM compatibility. #### IgnoreSignatures: bool (Default value is `$false`) Control signature detection behavior: -- `$false` (default): Automatically detect signatures. Signed scripts get selective checking, unsigned get full checking. -- `$true`: Bypass signature detection. ALL scripts get full CLM checking regardless of signature status. +- `$false` (default): Automatically detect signatures. Signed scripts get selective checking, + unsigned get full checking. +- `$true`: Bypass signature detection. ALL scripts get full CLM checking regardless of signature + status. ```powershell @{ @@ -95,7 +109,8 @@ Control signature detection behavior: } ``` -**Use `IgnoreSignatures = $true` when:** +Use `IgnoreSignatures = $true` when: + - Auditing signed scripts for complete CLM compatibility - Preparing scripts for untrusted environments - Enforcing strict CLM compliance organization-wide @@ -109,17 +124,20 @@ Use allowed cmdlets or pre-compile assemblies. ### Replace Disallowed COM Objects -Use only allowed COM objects (Scripting.Dictionary, Scripting.FileSystemObject, VBScript.RegExp) or PowerShell cmdlets. +Use only allowed COM objects (Scripting.Dictionary, Scripting.FileSystemObject, VBScript.RegExp) or +PowerShell cmdlets. ### Replace Disallowed Types -Use allowed type accelerators (`[string]`, `[int]`, `[hashtable]`, etc.) or allowed cmdlets instead of disallowed .NET types. +Use allowed type accelerators (`[string]`, `[int]`, `[hashtable]`, etc.) or allowed cmdlets instead +of disallowed .NET types. ### Replace PowerShell Classes Use `New-Object PSObject` with `Add-Member` or hashtables instead of classes. -**Important**: `[PSCustomObject]@{}` syntax is NOT allowed in CLM because it uses type casting. +> [!IMPORTANT] +> `[PSCustomObject]@{}` syntax is NOT allowed in CLM because it uses type casting. ### Avoid XAML @@ -135,9 +153,9 @@ Use modules with Import-Module instead of dot-sourcing when possible. ### Fix Module Manifests -- Replace wildcard exports (`*`) with explicit lists -- Use `.psm1` or `.dll` instead of `.ps1` for RootModule/NestedModules -- Don't use ScriptsToProcess as it loads in the caller's scope and will be blocked. +- Replace wildcard exports (`*`) with explicit lists. +- Use `.psm1` or `.dll` instead of `.ps1` for RootModule/NestedModules. +- Don't use `ScriptsToProcess`. These scripts are loaded in the caller's scope and are blocked. ## Examples @@ -219,7 +237,7 @@ function Process-Text { ```powershell class MyClass { [string]$Name - + [string]GetInfo() { return $this.Name } @@ -300,12 +318,15 @@ param([hashtable[]]$Configuration) ## Detailed Restrictions ### 1. Add-Type -`Add-Type` allows compiling arbitrary C# code and is not permitted in CLM. + +`Add-Type` allows compiling arbitrary C# code and isn't permitted in CLM. **Enforced For**: Unsigned scripts only ### 2. COM Objects + Only three COM objects are allowed: + - `Scripting.Dictionary` - `Scripting.FileSystemObject` - `VBScript.RegExp` @@ -315,7 +336,9 @@ All others (Excel.Application, WScript.Shell, etc.) are flagged. **Enforced For**: Unsigned scripts only ### 3. .NET Types + Only ~70 allowed types including: + - Primitives: `string`, `int`, `bool`, `byte`, `char`, `datetime`, `decimal`, `double`, etc. - Collections: `hashtable`, `array`, `arraylist` - PowerShell: `pscredential`, `psobject`, `securestring` @@ -323,6 +346,7 @@ Only ~70 allowed types including: - Arrays: `string[]`, `int[][]`, etc. (array of any allowed type) The rule checks type usage in: + - Parameter type constraints (**always enforced, even for signed scripts**) - Variable type constraints - New-Object -TypeName @@ -333,6 +357,7 @@ The rule checks type usage in: **Enforced For**: Parameter constraints always; others unsigned only ### 4. PowerShell Classes + The `class` keyword is not permitted. Use `New-Object PSObject` with `Add-Member` or hashtables. **Note**: `[PSCustomObject]@{}` is also not allowed because it uses type casting. @@ -340,16 +365,19 @@ The `class` keyword is not permitted. Use `New-Object PSObject` with `Add-Member **Enforced For**: Unsigned scripts only ### 5. XAML/WPF + XAML and WPF are not permitted in CLM. **Enforced For**: Unsigned scripts only ### 6. Invoke-Expression + `Invoke-Expression` is restricted in CLM. **Enforced For**: Unsigned scripts only ### 7. Dot-Sourcing + Dot-sourcing (`. $PSScriptRoot\script.ps1`) may be restricted depending on source location. **Enforced For**: ALL scripts (unsigned and signed) @@ -357,6 +385,7 @@ Dot-sourcing (`. $PSScriptRoot\script.ps1`) may be restricted depending on sourc ### 8. Module Manifest Best Practices #### Wildcard Exports + Don't use `*` in: `FunctionsToExport`, `CmdletsToExport`, `AliasesToExport`, `VariablesToExport` Use explicit lists for security and clarity. @@ -364,6 +393,7 @@ Use explicit lists for security and clarity. **Enforced For**: ALL .psd1 files (unsigned and signed) #### Script Module Files + Don't use `.ps1` files in: `RootModule`, `ModuleToProcess`, `NestedModules` Use `.psm1` (script modules) or `.dll` (binary modules) for better performance and compatibility. @@ -372,7 +402,13 @@ Use `.psm1` (script modules) or `.dll` (binary modules) for better performance a ## More Information -- [About Language Modes](https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_language_modes) -- [PowerShell Constrained Language Mode](https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/) -- [PowerShell Module Function Export in Constrained Language](https://devblogs.microsoft.com/powershell/powershell-module-function-export-in-constrained-language/) -- [PowerShell Constrained Language Mode and the Dot-Source Operator](https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode-and-the-dot-source-operator/) +- [About Language Modes][01] +- [PowerShell Constrained Language Mode][03] +- [PowerShell Module Function Export in Constrained Language][04] +- [PowerShell Constrained Language Mode and the Dot-Source Operator][02] + + +[01]: https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_language_modes +[02]: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode-and-the-dot-source-operator/ +[03]: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/ +[04]: https://devblogs.microsoft.com/powershell/powershell-module-function-export-in-constrained-language/ diff --git a/docs/Rules/UseSingleValueFromPipelineParameter.md b/docs/Rules/UseSingleValueFromPipelineParameter.md index bfaa3fe6a..92c350eb4 100644 --- a/docs/Rules/UseSingleValueFromPipelineParameter.md +++ b/docs/Rules/UseSingleValueFromPipelineParameter.md @@ -1,6 +1,6 @@ --- description: Use at most a single ValueFromPipeline parameter per parameter set. -ms.date: 08/08/2025 +ms.date: 03/20/2026 ms.topic: reference title: UseSingleValueFromPipelineParameter --- @@ -10,18 +10,15 @@ title: UseSingleValueFromPipelineParameter ## Description -Parameter sets should have at most one parameter marked as -`ValueFromPipeline = true`. +Parameter sets should have at most one parameter marked as `ValueFromPipeline = true`. -This rule identifies functions where multiple parameters within the same -parameter set have `ValueFromPipeline` set to `true` (either explicitly or -implicitly). +This rule identifies functions where multiple parameters within the same parameter set have +`ValueFromPipeline` set to `true` (either explicitly or implicitly). ## How -Ensure that only one parameter per parameter set accepts pipeline input by -value. If you need multiple parameters to accept different types of pipeline -input, use separate parameter sets. +Ensure that only one parameter per parameter set accepts pipeline input by value. If you need +multiple parameters to accept different types of pipeline input, use separate parameter sets. ## Example @@ -33,11 +30,11 @@ function Process-Data { param( [Parameter(ValueFromPipeline)] [string] $InputData, - + [Parameter(ValueFromPipeline)] [string] $ProcessingMode ) - + process { Write-Output "$ProcessingMode`: $InputData" } @@ -53,7 +50,7 @@ function Process-Data { param( [Parameter(ValueFromPipeline)] [string] $InputData, - + [Parameter(Mandatory)] [string] $ProcessingMode ) @@ -62,10 +59,11 @@ function Process-Data { } } ``` + ## Suppression -To suppress this rule for a specific parameter set, use the `SuppressMessage` -attribute with the parameter set name: +To suppress this rule for a specific parameter set, use the `SuppressMessage` attribute with the +parameter set name: ```powershell function Process-Data { @@ -74,7 +72,7 @@ function Process-Data { param( [Parameter(ValueFromPipeline, ParameterSetName='MyParameterSet')] [string] $InputData, - + [Parameter(ValueFromPipeline, ParameterSetName='MyParameterSet')] [string] $ProcessingMode ) @@ -92,10 +90,10 @@ For the default parameter set, use `'default'` as the suppression target: ## Notes -- This rule applies to both explicit `ValueFromPipeline = $true` and implicit - `ValueFromPipeline` (which is the same as using `= $true`) +- This rule applies to both explicit `ValueFromPipeline = $true` and implicit `ValueFromPipeline` + (which is the same as using `= $true`) - Parameters with `ValueFromPipeline=$false` are not flagged by this rule -- The rule correctly handles the default parameter set (`__AllParameterSets`) - and named parameter sets -- Different parameter sets can each have their own single `ValueFromPipeline` - parameter without triggering this rule +- The rule correctly handles the default parameter set (`__AllParameterSets`) and named parameter + sets +- Different parameter sets can each have their own single `ValueFromPipeline` parameter without + triggering this rule