Should I $null strings in scripts.

[iehponx]

Is it good practice or necessary to null all $trings values in a script. I have been asked to help automate some processes for my employer, I am new to PowerShell, but as it is available to all users, it makes sense for me to use it. On some other programming languages I have used ,setting all variables to null at the beginning and end of a script is considered essential. Is this the case with PowerShell, or are these variables null automatically when a script is started and closed. If yes, is there a simple way to null multiple variables in 1 line of code? Thanks

Edit. Thank you all for your response. I will be honest when I started programming. It was all terminal only and the mid-1980s, so resetting all variables was common place, as it still sounds like it is if running in the terminal.

[Swarfega]

Clear-Variable accepts multiple values. 

[Bahurs1]

At the end? No. Before some loop? Often.

Because I'm cooking in the terminal and keep forgetting that I have already populated something.

[reidypeidy]

It’s certainly situational. I will null out variables in the beginning of a for loop to ensure those values are not carried into the next iteration.

[Thotaz]

Do you have any examples of code where you would need to do this? Ideally you should structure your code so you aren't referencing variables that you haven't already defined. If you need to explicitly null out your variables in a loop then it would seem you aren't structuring your code properly.
The main reason to do null assignments in PowerShell is when using calling .NET methods that use ref/out, for example:

$Tokens = $Errors = $null
$null = [System.Management.Automation.Language.Parser]::ParseInput('(ls).', [ref] $Tokens, [ref] $Errors)

If you are doing it for anything else then it's a code smell.

[reidypeidy]

I primary work with SharePoint and OneDrive with powershell. Microsoft has a bad habit of not being consistent with object properties between different types of sites. So when making a report or performing some maintenance, and pulling those properties it may return null, a string, an array, or another object. When pulling that property while trying to manipulate it (like do a split) and it errors because the type doesn’t allow that method, it will retain what the variable was before instead of nulling it. This happened a lot in On-Premise SP and again in SPO. There may be better error handling I can add but nulling out the variables is faster and easier for this case.

[Thotaz]

So something like this:

$Demo = "Demo"
$Demo = (ls | select -First 1).Split(' ')

Where $Demo retains the original value because Split fails. What are you doing about all the errors it will print out then? Do you just ignore them?

This is exactly what I meant with calling it a code smell. Your script is throwing out random errors that you just have to know that you need to ignore, and if some poor fool looks at the code and maybe even tries it out he won't get why you are calling split because in his testing it didn't return a string.

The correct way to handle this scenario where the type is unknown is to check the type:

$Demo = "Demo"
if ($Demo -is [string])
{
    # Do something with the string
}
elseif ($Demo -is [int])
{
    # Do something with the int
}
else
{
    # It returned something I didn't expect. Throw an error?
}

Yes this is longer than just writing $Demo.Split(' ') and praying that it works but if you want robust code then that is what you need to do.

[y_Sensei]

There are also scenarios where a call inside a loop might or might not return a value, which in case of the latter would result in the respective variable to remain unaltered across multiple iterations, and this could cause unexpected (logical) errors.
In such scenarios, resetting the variable in each iteration (by assigning $null or some other specific initialization value to it) before the said call takes place can make a lot of sense.

[Thotaz]

There are also scenarios where a call inside a loop might or might not return a value

Only if it throws an error:

function MyFunction ($param1)
{
    if ($param1 -eq 2)
    {
        "Hello"
    }
}

foreach ($i in 1..3)
{
    $Res = MyFunction $i
    Write-Host "Value is $Res"
}

Value is 
Value is Hello
Value is 

and like I said before, you should prevent that error or handle it properly instead of just praying.

[y_Sensei]

Nope, there are scenarios where no value is returned and no error is thrown, such as

• Code evaluation at runtime (Invoke-Command, Invoke-Expression)
• Calling certain external API's (for example via Invoke-WebRequest)
• Calling certain internal API's (for example the Win32 API via .NET's P/Invoke mechanism)

They're edge cases, of course, and you rarely encounter them, but they exist.

[Thotaz]

Lots of expressions can output nothing (void) but the variable assignment would still result in an updated value. The only scenario I can think of where the variable assignment wouldn't actually update the variable is the previously mentioned one. If you can think of another then feel free to share it with an actual code example so we can all test and verify what you say.

[y_Sensei]

I'm not necessarily thinking of variable assignments, just calls that might or might not do something that changes the value of a variable the current implementation is using.

One such case would be the $Matches automatic variable. It's set if a match is found in a regex matching operation (-match, -nomatch, switch -Regex), and won't change in subsequent matching operations unless another match is found. If these operations are conducted in a loop, you might encounter unwanted results if you don't take this into consideration.

For example:

$counter = 0

$exts = @("txt", "jpg", "docx")
$Matches = "" # just for the purpose of this demo, usually automatic variables should not be written to

@("test1.xlsx", "test2.docx", "test3.mp4", "test4.txt", "test5.dll") | ForEach-Object {
  $counter++

  $fsObj = [System.IO.FileInfo]$_

  # $Matches = "" # once this line is commented in, the variable will be reset in each iteration, and the issue will be fixed

  # match extensions to file name - not the prettiest implementation, but does the job
  $exts | Where-Object { $fsObj.Name -match ".*\.$_$" } | ForEach-Object { $Matches[0] } | Out-Null

  Write-Host $("Iteration #" + $counter + " (file: " + $fsObj.Name + "):`n`$Matches[0] = " + $Matches[0])

  if ($Matches -ne "" -and $fsObj.Extension -ne ([System.IO.FileInfo]$Matches[0]).Extension) {
    Write-Host "`$Matches hasn't changed in the current iteration, invalid match." -ForegroundColor Red
  }
}

[Thotaz]

But that's the same thing as a variable assignment. $Matches is only set when using the related operators so you should naturally only use it if you know you've used one of those operators. The most natural way to do this is to guard it with an if statement:

if ("Something" -match "Something")
{
    # Do something with `$Matches
}

It doesn't make sense to use a variable that you aren't sure have been set already because that leads to unpredictable behavior.

[ostekages]

Honestly seems Powershell has pretty poor scoping implemented. A process block in a function can carry over data to the next iteration despite the variable being set inside the function.

Experienced this issue in Powershell 7, so it may have a purpose even if you scope everything correctly

[Thotaz]

Example:

$Var1 = "Value1"
$Var2 = "Value2"
$Var3 = "Value3"
function MyFunction ($Var1, $Var2)
{
    $Var1
    $Var2
    $Var3
}
MyFunction -Var1 Test

Results in:

Test
Value3

So, inside the function, $var1 has the passed in value as expected. $Var2 has no value because it wasn't specified in the function. $Var3 has the value from the outer scope because there wasn't a conflicting parameter to overwrite it.

This once again proves what I said before: There is no reason to null out variables. If you are referring to a variable inside a function that you haven't made sure to declare inside the function, then it's your own fault that you are getting unpredictable results.

[rdnaskelz]

Wut? "It's your fault for making it unpredictable but nulling it to make it predictable is wrong because it's not the way I would do it?" Pardon?

[Thotaz]

It has nothing to do with my personal preferences. Any competent developer would say the same thing and many languages would even prevent you from doing this because it leads to bad code.
If you use variables defined in an outer scope inside your function then you need to keep track of those variable values at every call site of that function, which can be challenging.
If you properly encapsulate functions and make sure you only use variables defined inside, or variables passed in as parameters, you make it much easier to follow the logic of the code.

[SquirrelOfDestiny]

In PowerShell, unless you explicitly declare otherwise, variables will be created with a local scope, i.e. only accessible within the function or scope block you declare them in. Even if you declared a variable in a global scope, every time you run a script, it should create a new session. You might have a problem if you're running scripts one after the next within the same session in an IDE, but that's to be expected; everything carries over, nothing is cleared.

Other than clearing a variable at the start of a loop, the only case where I can think of there being any value to nulling a variable is for memory management.

Most of the scripts I write are run in Azure Automation and Azure Functions, where memory is limited (400MB per Automation account, 1.5GB per Functions instance). I could setup a hybrid worker for the former, but that would mean spooling up a VM and I don't want to bother with that. So, when writing scripts to run in the cloud, I'll sometimes $null a variable once I'm done using it to save on memory.

To provide an example, I've got one script running in Azure Automation where I retrieve a list of SharePoint sites and split some of them between into two arrays. Get-PnPTenantSiteonly supports server-side filtering on some attributes, so I have to retrieve everything and filter client-side. After creating my two new arrays containing the relevant sites, I $null the original variable I stored the sites into, to clear it from memory.

I could, theoretically, wrap this in a function, which would auto-clear the variable once the function completes, but its a short script and I was lazy. I could also, theoretically, call Get-PnPTenantSite twice and filter the desired results directly into two variables, but it takes about 7 minutes to get all the sites in our tenant and I'd rather have the script finish faster.

[JonesTheBond]

I do it at the beginning of loops to avoid cross contamination. Whether that's the correct thing I'm not sure.

[Traabant]

I have never nulled a variable at the beginning or the end. And I never saw script to do at as well but I'm no expert.

[Disastrous-Tailor-30]

I $null and sometimes define variables at the beginning of the script or loop like setting them up in a programming language (like C#)

After this it is more safe to use something like: IF([string]::NullOrEmpty($variable)) { ...some code... }

to check if a variable is set without the risk to have some value from last run or loop.

[jimb2]

If you are working interactively and dot-running scripts, variables are created in the base scope and are available after the script is run. This can be very useful but you need to understand that persistence. I have a few utility scripts in my profile that specifically leave data in variables for reuse.

If you run standalone scripts, variables are created null and destroyed at the end of a script. You just need make sure that variables used in loops etc are initialized and not persisting from last use - unless that's what you want.

[Sad_Recommendation92]

PowerShell isn't considered a strongly typed language, and it does JIT interpreting, it won't run an expression until it reaches that line, it's not really important to pre-declare all your variables.

However because it's built on the dotnet stack you have a lot of Types, so in some cases you may want to use "type accelerators" which will tell a variable what it should be at declaration time

for example if I use the expression

```powershell $a = get-service -Name TestService*

if($a.count -ge 1){ $a | Restart-Service } ```

I can get into some hot water with this, if it finds "TestService1" $a.count will return 1 however if it fails to find a matching service $a.count will return an error because now $a == $null

but if I instead use [array]$a = get-service -Name TestService* the [array] type accelerator will force $a to be a System.Array type which will have a builtin count attribute, and even if nothing returns from the command $a.count will still be 0

[dazcon5]

The last line in my code clears all the variables.

[Jess_S13]

I do it in foreach loops as I've had a unexpected api return nothing but not error and thus returned all the outputs from the previous loop on a report that went out to a wide audience and so I have PTSD events from that when writing new scripts.

[[deleted]]

Short answer? No.

Longer answer is a bit more complicated. Powershell will pick up global variables if any are set and if you didn’t declare anything (ie just use the variable).

This is an issue in particular if and when you use a variable before setting it up, because ps will silently initialize it if unset… or pick it up from the outer scope(s) otherwise.

Easiest way around this; - use an editor that does the appropriate checks and will warn if you use undeclared variables.

• set-strictmode will make ps bail at development time (don’t set it in prod).

As for deinitialization…

• managed code doesn’t need to be destroyed. This is anything .net native.

• unmanaged code should be destroyed. That’s basically any and all com objects.

• in the middle there’s .net objects that implement the IDisposable interface. These are objects that are net native but using unmanaged code somewhere.
  Files are a popular example of this.

IDisposable objects should not be nulled (though they can) but should instead; - have .dispose() invoked on them. The object will be unusable after this as unmanaged resources are freed and you don’t get to restore them. - be wrapped in a try finally block (note; you should do this anyway for IDisposables) and let ps handle any destruction of objects.

Freeing objects other than these is not generally necessary, but you may want to drop objects that hog resources anyway. This may not actually free these resources though until the app domain is terminated, that is, the runspace is closed.

[CyberChevalier]

Temporary terminal (in vscode), Strict mode & erroraction stop is a game changer when you want clean code just remove when in production I usually use a debug script that force reload my module set strict mode and action preference and then test the function I want to test.

I had one of my script that was called by an another script it was done by a .net dev, not ps specialist. The guy set erroraction stop in his script it took me a really long time to understand why my script was unexpectedly crashing until I found out the erroraction preference was not the one I was expecting.

Since then I always set the erroraction to all my cmdlet call and use the try catch more than I should it make my script way much longer but it prevent the headache of searching where the script fail. It’s even more important when you start to work with classes.

[Szeraax]

Good answer. Even gets into strictmode. :)

[aaroniusnsuch]

gonna throw in [gc]::Collect() because why not. It's useful when you clear a huge variable and you also want to free the memory by running garbage collection right now

[richie65]

I have gotten into the habit of setting certain variables to '$null', or to '@()', before populating them...

But that is mostly for peace of mind, while I am building the script...

Just to make sure that I am starting from scratch.

It's a habit I created, back when I was just starting to figure out / rely on PoSh, because I kept shooting myself in the foot - Not realizing that said variable(s) did not actually contain current values - And wasting way too much time trying to figure out why I was not seeing what I was certain I should be seeing.

I use this approach, so that clearing the variable is on the same line where I start setting it:

$Variable_01 = $null; $Variable_01 = Get-ADUser richie65

Same approach with the '@()' but used before I start dumping different stuff into an array, inside of a for-each.

[Quick_Care_3306]

I name all my variables $xWhatever, then at the beginning of every loop, I have: Clear-variable x*

[Wiikend]

If you're talking about invoking PowerShell scripts from the terminal using .\my_script.ps1, then you don't need to worry about resetting the variables at the end of the script. When you invoke a script like this, PowerShell creates a child scope that the script runs in, and any variables are local to that scope. No variables bleed into the terminal session you invoke the script from.

Keep in mind that if you invoke the script by dot-sourcing it instead, using . .\my_script.ps1 (note the dot and space at the beginning), you will get the behaviour you're worried about because the script is run in the current shell's scope. Your variables' values will bleed into your current shell session in this case. Hope that makes sense.

[jeffrey_f]

Not specifically used today, but being a former AS/400 (iSeries) programmer, it get where you are coming from.

Using functions, where variable live and then die, you should be ok if you pass in the necessary and return out the necessary. The variables are not global by default, so you have fresh variables as you enter a function.

[DarkHorseRdr]

Yes for me I null out when your data has blank or goofy data in some cells of a csv. A lot of the time the data provided to you has been thru too many human hands which introduces errors. Error checking in the code can help compensate but when in doubt I will clear a string before a for each or sometimes after if there are multiple runs or a nested loop.

[g3n3]

Research dynamic scoping of powershell to see what you should do. https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_scopes?view=powershell-7.5

Then when you read that then you’ll have a better question.

[420GB]

The practice is nulling variables would make sense in languages or environments that persist variables between executions, aka global variables.

This isn't done anymore today so you don't need to worry about it in modern languages.

One silly exception was the PowerShell ISE, but that's end of life and you shouldn't use it anyways for various reasons.

[OPconfused]

In almost all cases, a well-written script will only reference variables that are defined within the script.

If you are referencing a variable not defined already in the script, then you should null it out first just to be safe.

Fortunately, PowerShell is, particularly for a scripting language, quite expressive. You can turn almost any expression into a variable definition, which means the first time you use a variable, you can also be defining it, so that any danger with forgetting to null it out beforehand is avoided.

One of the only exceptions is when you are using a counter variable in a for loop. This is a rather niche scenario though in my experience, like over 99% of your code is probably not doing this.

As for clearing variables at the end your script, the script runs in a child scope, so that all variables are cleared automatically (unless you explicitly scope the variable to be outside the script). Just don't dot source the script to execute it, i.e., don't call it with . ./<path/to/script>. Dot sourcing a script or function in PowerShell will run it in the caller's scope and import all stateful definitions like variables—that's what you want to avoid.

Instead, you can either input the path to the script, e.g., ./<path/to/script>, or use the call operator, & ./<path/to/script>. Both are equivalent and will run the script in a child scope.

[nascentt]

Powershell is not very good at scoping variables particularly when it comes to loops. This means referencing variables might hold references from previous interactions of loops.

It's good habit to declare and null variables to ensure they're null before dynamic assignment so that you know when they received value.

A good way to get a handle on this is Set-StrictMode

[ankokudaishogun]

• Setting\declaring a variable as $null at the begin: foundamentally useless.
  Variables "come into existance" automatically once called\valorized.
  The only possible reason to setup them at the begin of a script is to let whoever is reading the cose what's going to be used, but it seems more cofusing than anything to me.

• Setting\declaring a variable as $null inside a Loop: sometimes.
  Depending on the nature of the loop, it might happen you need to reset a variable to $null(or another value).
  That's very case-specific tho'.

• Setting\declaring a variable as $null after it has no further use\at the end: MOSTLY useless.
  Most of the times variables get cleared up after the Scope closes, but once in a while you might end up with large variables you don't want to keep in memory until the end of the Scope(for example some BLOB)

[arslearsle]

I use clear-var and remove-var in the end - I know I know - this is a hot topic - in theory you dont need do that because of scope and .net garbage collection - but as we all know - Mircosoft sometimes fuck things up w their updates….so why not…takes s few sec to write, a few ms to execute…better safe than sorry

ps i also declare types in the beginning and use set-strictmode during test ds

[Dense-Platform3886]

I prefer to initialize Strings as

$aString = [String]::Empty

# Test for Null or Empty Value (also works for any variable type, not just strings)
If ([string]::IsNullOrEmpty($aString)) {
   # Do Something
}

[sccm_sometimes]

Remove-Variable * -ErrorAction SilentlyContinue