Repository navigation
PSUseCorrectCasing: operators casing treated differently #2136
Description
I'm tracking down a weird regression coming from 1.18.2 to 1.24.0.
UseCorrectCasing reports that if enabled, operators will be set to their "lowercase" format. But treatment of operators seems different, particularly within expressions.
Steps to reproduce
'@{ Rules = @{ PSUseCorrectCasing = @{ Enable = $true } } }' > rules.psd1
$scriptDefinition = @'
if ($name -EQ 'foo')
{
Write-Message "hi"
}
$coll = @()
$coll += [pscustomobject]@{
Name = 'bar'
}
if (-not ($coll | Where-Object Name -eq 'bar'))
{
Write-Message "hi!"
}
'@
Invoke-ScriptAnalyzer -Settings rules.psd1 -ScriptDefinition $scriptDefinitionExpected behavior
Line 1 should be switched to -eq
Line 9 should stay as -eq
Actual behavior
RuleName Severity ScriptName Line Message
-------- -------- ---------- ---- -------
PSUseCorrectCasing Information 1 Operator '-EQ' does not match the expected case '-eq'.
PSUseCorrectCasing Information 9 Function/Cmdlet '-eq' does not match its exact casing 'EQ'.
The devil may be in the details, but why one operator (line 1) is detected as "an operator" while the one on line 9 is detected as a "Function/CmdLet" ?
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 7.5.3
PSEdition Core
GitCommitId 7.5.3
OS Microsoft Windows 10.0.26200
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
> (Get-Module -ListAvailable PSScriptAnalyzer).Version | ForEach-Object { $_.ToString() }
1.24.0
Activity
potatoqualitee commentedon Oct 30, 2025
Yes pls, would appreciate a solution 🙏🏼
liamjpeters commentedon Oct 31, 2025
👋 Simone Bizzotto (@niphlod),
The rule is doing the right thing, albeit with some docs and messaging that need some updates.
$name -EQ 'foo'is an expression and-EQis the equality operator. The rule's documentation says it's going to lowercase operators, and it does.Where-Object Name -eq 'bar'looks similar to an expression, but is actually a command invocation, calling theWhere-Objectcmdlet and using it's-EQparameter. This, annoyingly, is uppercase as defined.The rule's documentation says that it will require all commands to match their actual casing. Indeed it's looking up the defined casing of command names and their parameters and flagging when they don't match.
The rule's documentation and diagnostic message could be clearer.
In the Parameters section of the rules docs, the description of
CheckCommandsandCheckOperatorlook to be swapped.CheckCommandsdoesn't call out it operating on parameters too.The diagnostic message calls it out as a "function/cmdlet", despite being a parameter. The code knows it's a parameter, but uses the same message that it does for mis-cased command names. A parameter specific diagnostic message should be added.
Does that help clear things up?
niphlod commentedon Oct 31, 2025
ohhhh shucks. okay Liam Peters (@liamjpeters) , now I get it. Okay, so I think this can be closed, and what really highlighted is just a documenting touchup
liamjpeters commentedon Oct 31, 2025
This does look to be a regression from when #1704 was merged earlier this year.
There was previously a message regarding parameters.
I'll get the parameter message added back in and the docs updated