PSUseCorrectCasing: operators casing treated differently

[niphlod]

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 $scriptDefinition

Expected 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

[potatoqualitee]

Yes pls, would appreciate a solution 🙏🏼

[liamjpeters]

👋 @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 -EQ is 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 the Where-Object cmdlet and using it's -EQ parameter. This, annoyingly, is uppercase as defined.

  Where-Object
    [-Property] <String>
    [[-Value] <Object>]
    [-InputObject <PSObject>]
    [-EQ]
    [<CommonParameters>]

  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 CheckCommands and CheckOperator look to be swapped. CheckCommands doesn'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]

ohhhh shucks. okay @liamjpeters , now I get it. Okay, so I think this can be closed, and what really highlighted is just a documenting touchup

[liamjpeters]

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