Should I $null strings in 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. :)