You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RuleName Severity ScriptName Line Message
-------- -------- ---------- ---- -------
PSUseDeclaredVarsMoreThanAssignment Warning Analyzer.p 3 The variable 'a' is assigned but never used.
s s1
If an unexpected error was thrown then please report the full error details using e.g. $error[0] | Select-Object *
RuleName Severity ScriptName Line Message
-------- -------- ---------- ---- -------
PSUseDeclaredVarsMoreThanAssignment Warning ConvertTo- 208 The variable 'Space' is assigned but never used.
s Expression
.ps1
PSUseDeclaredVarsMoreThanAssignment Warning ConvertTo- 208 The variable 'LineUp' is assigned but never used.
s Expression
.ps1
@iRon7 The rule implementation is limited in its analysis to a scriptblock, which is a function here, therefore it cannot see the 'usage'. Because PowerShell propagates all variables to lower scopes (i.e. when you call a function), one technically does not need to pass variables explicitly but it is highly discouraged from a code readability/maintainability perspective. Therefore I strongly suggest to add a parameter to your Get-A function so that you can see the flow of dependencies/arguments and this will also 'fix' the PSScriptAnalyzer warning.
Thank you for the answer,
I think that I have oversimplified my mvce.
In my case, the concerned Get-A function has already a lot of parameters and the concerned variable $a merely is a public setting/mode (which less meaning) for every (recursive) function called down the line.
Anyways, I basically agree with your statement, but question whether there are any justified exceptions to this rule.
I have been thinking about this for quite some time and I do not know the answer...
Steps to reproduce
I am not sure whether this is a duplicate of #636 and/or the implication is completely understood:
Expected behavior
Actual behavior
If an unexpected error was thrown then please report the full error details using e.g.
$error[0] | Select-Object *
Used case:
https://github.com/iRon7/ConvertTo-Expression/blob/master/ConvertTo-Expression.ps1
Environment data
The text was updated successfully, but these errors were encountered: