Fix PSAvoidUninitializedVariable warning on non-mandatory Parameter

[rkeithhill]

I have a non-mandatory parameter that is defined like so:

    [Parameter()]
    [ValidateNotNullOrEmpty()]    
    [string]
    $NuGetVersion,

This is generating a warning:

Variable 'NuGetVersion' is not initialized.
Non-global variables must be initialized. To fix a
violation of this rule, please initialize non-global
variables.

While parameter may not be global variables, their initial value is typically provided outside the scope of the function. I've used parameter checks against $null to test if the parameter was supplied. I guess I could initialize these parameters to some value (say $null). I'm just not convinced that all non-mandatory parameters should be initialized with a default value.

Here's an example where initialization gets tricky due to value types:

function foo {param([Parameter()][DateTime]$d) "d is $($d -eq $null)"}

Parameter $d is not initialized and this would gen a warning. However, if I try to set $d to $null that will error saying that null can't be converted to DateTime. However if no argument is passed for $d, the function above will return True - $d is equal to $null in this scenario. So to eliminate this warning I have to initialize to some valid DateTime value - blech. I guess I could resort to checking $PSBoundParameters but that seems clunky when a simple $null check would suffice.

[raghushantha]

Hi Keith.

For reference types, the default initialization is $null, for value types it is [T]::New().
Hence the default initialization is usually sufficient.

The purpose of this rule is to improve code readability and avoid unintended consequences when using uninitialized variables. Hence the Severity is "Warning" only.

If this is creating a lot of noise, then there are two ways to prevent this rule from being applied:

1. Use -ExcludeRule parameter - Invoke-ScriptAnalyzer
2. Use Suppress inline attribute
   Ex: https://github.com/PowerShell/PSScriptAnalyzer/blob/master/Tests/Engine/RuleSuppression.ps1

-Raghu

[GoodOlClint]

To expand a little on what Raghu said above, here's a Hey, Scripting Guy! article on uninitialized variables.

In your example, I'd initialize to some standard date (January 1, 1980 is a popular one). Then you don't need to validate ($d -ne $null) followed by whatever else you need to check, you let Powershell handle the null check and you do your date validation on your own.

Alternatively, you can set your Parameter type to [Nullable[DateTime]] and it will allow you to set $null as the default value.

[rkeithhill]

I figured it was probably something like this. I just don't know that I agree. Defining a type a [Nullable[DateTime]] isn't going to be particularly sysadmin friendly i.e. they see the docs wonder that the heck a [Nullable[DateTime]] is. Of course the same issue exists for any value type e.g. [int]$Count. Presumably you don't require a switch parameter to be initialized.

Another thing is that sometimes the way you check to see which parameters to use is to test to see which ParameterSetName is in effect. I would recommend that you not warn on uninitialized parameters. This is going to generate lots of warnings as the "conventional" approach for years has been to only initialize parameters when you want there to be a default value. I'm looking at the Pester module that ships with Windows 10 and the majority of its function parameters are not initialized.

[rkeithhill]

How about a compromise here. You should be able to differentiate between parameters and variables. Create a new rule PSAvoidUninitializedParameters so that I can suppress that rule and still get the benefit of the PSAvoidUninitializedVariables rule.

[GoodOlClint]

I've added a branch to my copy of PSScriptAnalyzer with this new rule.

It's still a work in progress but please try it out and see if it will work.

[rkeithhill]

Yeah, that looks pretty good. The message needs to be updated as it still refers to uninitialized variables:

Parameter 'Days' is not initialized. Non-global
variables must be initialized. To fix a violation of
this rule, please initialize non-global variables.

I think this is a step the right direction - treating parameters a bit differently than variables by giving them their own rule. Thanks!

[GoodOlClint]

Yeah, I literally cloned the code for variables and tweaked it around to make it work. I'll clean up the messages and submit a pull request to get this included.

[rkeithhill]

Just noticed that the rule is getting triggered on references to the parameter outside of the param() block. I don't think it should do that. This isn't the avoid uninitialized variables rule anymore. :-)

[GoodOlClint]

Yep, still working on it.

[rkeithhill]

Perhaps the message should be something like:

Parameter 'Days' may not be initialized. Optional parameters may not have been
supplied a value during invocation. Use $PSBoundParameters to determine if an
optional parameter was supplied or provide a default value for the parameter.

[GoodOlClint]

I think I've fixed the problem of the rule getting triggered outside param blocks.
Also, I had already updated the message to: "Parameter 'Param1' is not initialized. Parameters must have a default value. To fix a violation of this rule, please specify a default value for all parameters"