PSUseDeclaredVarsMoreThanAssignments false positive when used via Get-Variable

[thomasrayner]

The PSUseDeclaredVarsMoreThanAssignments rule will erroneously throw a warning if a variable is declared but only used via the Get-Variable cmdlet.

Steps to reproduce

Create a .ps1 file with the following contents.

$variable = 'a value'
Write-Output "The value is $((Get-Variable -Name 'variable').Value)"

Examine the file with PSScriptAnalyzer.

Invoke-ScriptAnalyzer -Path .\pssa-demo.ps1 -IncludeRule 'PSUseDeclaredVarsMoreThanAssignments'

A warning will be created.

RuleName                            Severity     ScriptName Line  Message
--------                            --------     ---------- ----  -------
PSUseDeclaredVarsMoreThanAssignments Warning      pssa-demo. 1     The variable 'variable' is assigned but never used.
                                                ps1

Screenshot

This is in addition to the issues this rules has when splatting or using in Invoke-Command, foreach-object loops, and others which have already got issues created for them. I couldn't find another open issue for this particular false positive.

[bergmeister]

Thanks for reporting the case. However, it is a known issue that PSUseDeclaredVarsMoreThanAssignments can produce false positives for more than a year and there are several similar issues in this repo already. Given the low ressources on this project from the Microsoft side at the moment, it might take quite some time until PSUseDeclaredVarsMoreThanAssignments get fixed. Nevertheless it is still good to have all use cases collateted to help testing it should someone step into doing this ambitious task.

[thomasrayner]

@bergmeister I checked the other issues on this repo for problems with this rule and found a few, but didn't see any for this particular false positive. Given the wide array of challenges with this rule, I often find myself telling junior scripters to omit this rule from their testing/review processes. I am certainly sympathetic that it can be hard to dedicate resources to issues like this one, but as you alluded to, sometimes it's just good to have the problem documented.

Perhaps there will be an enterprising member of the community who will feel compelled to re-write the PSUseDeclaredVarsMoreThanAssignments rule.

[bergmeister]

@ThmsRynr You can still just suppress the warning on a case by case basis. I also found that using script scope makes false positives go away sometimes. As an enterprising member of the community I have already done PRs on this repo and currently have 4 pending PRs here with 2 of them improving this rule, so feel free to contribute as well.

[thomasrayner]

Awesome! Looking forward to seeing them merged :)

[JamesWTruher]

@ThmsRynr, @bergmeister the PRs have been merged, could you take a look?

[bergmeister]

@JamesWTruher I tried it but the PRs did not fix this issue and the reason seems to be because the variable is accessed only indirectly. This issue is tricky and some people might even say it is by design because the variable itself is not used directly.
@ThmsRynr Can you give an example where you have to use Get-Variable to retrieve the variable value in this way? The purpose of the command is to retrieve variable values from multiple scopes, filtering etc but to me it looks a bit odd why you need to use the cmdlet for the simple special case of retrieving the variable value in the local scope? At the moment the following rewrite does not produce a warning and makes the code more readable:

$variable = 'a value'
Write-Output "The value is $variable"

[ingemar-hn]

I filed this bug (PowerShell/vscode-powershell#1226) on vscode-powershell. It got closed with reference to this bug.
It is probably the same problem causing this, it might just look different.

[bergmeister]

There are various known issues with false positives of this rule. The most similar one to the one reported by you is this one here. Small improvements have already been made to the rule in the meantime but this is a long ongoing progress of tweaking the rule that was initially written in a simplistic way to provide some value. The rule will effectively only become better once it uses SSA (single statement analysis) which is at the moment not completely implemented and a big undertaking.

[bergmeister]

There are various known issues with false positives of this rule. The most similar one to the one reported by you is this one here. Small improvements have already been made to the rule in the meantime but this is a long ongoing progress of tweaking the rule that was initially written in a simplistic way to provide some value. The rule will effectively only become better once it uses SSA (single statement analysis) which is at the moment not completely implemented and a big undertaking.
However, I do have an idea what could maybe fix the most common false positive positives related to using the += operator.