PSAvoidUninitializedVariable is currently causing more harm than good because it is trying to overreach its bounds. It generates a warning for variables that are properly initialized in other files (this happens when I use snippets). It generates warnings for function parameters that are not initialized (these should not be initialized as a best practice). It generates warnings if you use -ov to store the results from a command in a variable (although that should generate a warning about the -ov parameter alias instead). It generates warnings if you use Set-Variable to set the value of a variable in a scope other than the current scope. Each of these scenarios can and do happen in scripts, and none of them should generate warnings.
To further complicate the issue, if you want to suppress the warning in a script module (psm1) file, you have no choice but to suppress all instances of that warning. As a best practice, that would be the wrong thing to do. You should suppress only the specific instances where this rule fails to identify that a variable is initialized, or when this rule identifies that having a variable that is uninitialized is a bad thing when in fact it is not (parameters).
I really dislike this rule as a result of these issues, and seriously question its usefulness. I feel there are too many scenarios where this rule will show up when you don't want it. This rule by far generates the most noise across all of my modules that I am performing analysis on as well.
All of this raises an important question: where does PSScriptAnalyzer start overstepping its bounds? For example, this rule is about identifying variables that are used when they are uninitialized. But Set-StrictMode -Version Latest does that very thing, and it does it very well, at runtime. When you use strict mode, you will get an error if you try to reference a property or method on an uninitialized variable. I use strict mode as a best practice. That, combined with a proper test harness (Pester or something else) is a better solution to this problem than this rule, because those solutions will properly and accurately identify when a variable is used that is not initialized. And since they exist, why duplicate that effort in PSScriptAnalyzer in a semi-functional, noisy way where it shows up in places where you don't want it?
That said, I get the value of identifying these issues through static analysis. If you keep this rule around (which I suspect you will), you absolutely have to fix it so that it doesn't generate warnings on parameters, and you need a better suppression mechanism so that you can suppress it with the appropriate restrictions (for example, I would suppress it broadly for all use of PSModule and PSModulePath for my modules, because I initialize those in an external snippet. The current module does not seem to support a suppression like this (for specific variable names across any analysis I run), nor does it support suppression of this for specific variables in a script module file.
I felt this needed to be discussed with the community, so please share your thoughts if you have any to share.
The text was updated successfully, but these errors were encountered:
That works for a single variable, but only a single variable. If I enter
multiple SuppressMessageAttributes, each one for a different variable for
which I want to suppress this rule, only the last one is respected.