Strict Mode

[bryanwinstead]

What's the community's view on Strict Mode? Is there one? Should there be one?

[KirkMunro]

I use it religiously in modules and consider it a mandatory best practice for any PowerShell scripts/modules that you share with others.

For any module I create, in the manifest I invoke Set-StrictMode -Version Latest at the top, unless the module uses WMI (in which case there can be many errors with "Latest", so I limit it to -Version 2). The value for me is huge. PowerShell watches my back and raises errors that I may otherwise not have noticed, and by using it in my module I ensure that no matter where my module is imported, whether strict mode is being used or not, the module will work as it was intended.

I also use it religiously in standalone scripts I share, for the same reason.

Without it, if you share code with others you may have someone complain about errors that show up because the module/script was loaded somewhere that strict mode is enabled.

An alternative approach would be to explicitly turn strict mode off in your script module or shared standalone scripts if you don't want what it gives you and if you want to make sure that your content works if it is loaded somewhere else where strict mode is enabled, but I would only recommend doing that if strict mode actually generated incorrect errors that couldn't be worked around with proper coding (i.e. bugs in strict mode itself like the WMI issue, but in that case using version 2 works around the problem). I have yet to find anything other than the WMI issue with strict mode though, so I don't expect turning it off completely would be necessary.

Day to day though, I don't use script mode in ad-hoc command invocation in a PowerShell host because I have no need for it there. It's really only beneficial when you move into programming with PowerShell.

[nightroman]

unless the module uses WMI (in which case there can be many errors with "Latest", so I limit it to -Version 2)

This is interesting. Do you remember an example of the issue?

I have yet to find anything other than the WMI issue with strict mode though

Here is what I recorded:

• Surrogate properties Count and Length may fail, see Count-and-Length-in-Strict-Mode
• Out-String may fail in the strict mode with the default host, see Strict-mode-ErrorRecord-formatting (UPDATE: corrected, thanks to @KirkMunro)

The last issue is probably just a defect which eventually may be fixed. But the
first is probably by design and this rise another question: is it safe to
use surrogate Count and Length?

[KirkMunro]

Here's the WMI issue I was talking about with the "Latest" version of StrictMode (which really means anything higher than 2 as long as this issue exists):

Set-StrictMode -Version Latest
$c = gwmi -Class meta_class -Filter '__CLASS="Win32_Service"' -Amended
$c.Qualifiers['ThisQualifierDoesNotExist']

That last line will cause a terminating error to be raised, but only when using a strict mode that is greater than 2. If you change the -Version value from "Latest" to "2" on the first line, then the last line simply doesn't return anything, and no error is generated. It is confirmed to be a bug by Microsoft, and they have logged it internally, but it still exists in 5.0.10586. You can reproduce this by accessing other parts of WMI as well (e.g. $c.PSBase.Properties['DoesNotExist'] will give you the same behaviour), so it's not strictly related to retrieving amended data from WMI. Also, since these collections don't have a Contains or ContainsKey method (they aren't like hashtables or other dictionaries), there is no way to test for the presence of an index other than to attempt to retrieve it, so there isn't a valid workaround.

For surrogate properties failing, that is a feature of -Version 2 of StrictMode. Those properties only exist because of some syntactic magic that was added to fix bugs that would show up when people weren't writing proper code. Even with that syntactic magic added, I still advocate for wrapping anything you expect to be an array in array enclosures, because then it will always be an array, even if it only contains one item. All to say, from my perspective, it isn't safe to use surrogate Count and Length properties without explicitly tuning down your strict mode level, and if you're like me thinking that's not a compromise that you're willing to make with your code as a whole, then you'll opt for array enclosures instead because it's a whole lot less work to use them than it is to turn down strict mode just for a little bit of lazy programming.

For the Out-String issue, that's not a bug in Out-String. It's a bug in the format code for ErrorRecord objects defined in PowerShellCore.format.ps1xml. That logic is assuming too much information about $host, which is why the error occurs when StrictMode is version 2 or later. That code should coditionally check $host to ensure that it has a the properties it is looking for and if not, it should assume a default value for width. Right now it's just lucky logic because a $null value for $host.UI.RawUI.BufferSize.Width results in a negative value for the $width variable, and when you split on a negative length the string just doesn't split. It's buggy code regardless of the StrictMode value though because it isn't calculating the indent properly even when $host.UI.RawUI.BufferSize.Width is available, as can be seen by running this in the native PowerShell console:

try {
    throw 'Oops, I did it again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again!  And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again!  And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again!  And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again!  And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again! And again!  And again! And again! And again! And again! And again! And again! And again! And again! And again! And again!'
} catch {
}
$Error[0]

That formatting bug is only really visible when you have an error message that would span multiple lines. Notice how the line wrapping of that message is somewhat arbitrary, and the indent fades away as more lines are added. The logic in that format file should set strict mode to version 1 when trying to get the buffer width (like it does just about everywhere else -- this code isn't written very well), and then if the buffer width comes up as null it should assume a default width or explicitly not split the message (and not just by chance like it does right now). That code should also have the indentation logic fixed, but that's completely independent of strict mode impacts.

[nightroman]

@KirkMunro, thank you for interesting details and thoughts.

As for the the script analyzer, I am not sure. I use strict mode in my internal scripts and I test my public scripts with the strict mode enabled. But I normally do not publish code with the strict mode enabled. So I would prefer if the analyzer does not force me to use this mode.

[KirkMunro]

I agree that it shouldn't be forced by script analyzer. I wasn't proposing that, or anything related to script analyzer yet because these are my views and there is need for community consensus here. If anything is done in script analyzer with respect to strict mode, I would list it as recommended for modules (which are not dot sourced, and therefore current scope is not impacted), and I wouldn't do anything for scripts because script analyzer cannot identify whether the script will be dot sourced or not, and dot sourcing would impact strict mode in the current scope. Functionality that should be run with script mode enabled is primarily modules, in my opinion, because those are more of a programming entity. It can't be forced at all though because PowerShell is a scripting language first, and while I prefer using it as a programming language, the majority of the PowerShell community are simply not there and don't think that way.

[nightroman]

My bad, I mentioned the script analyzer but was rather thinking of recommendations and gudelines.

The recommendation for enabling strict mode in modules makes sense and looks good.

[Jaykul]

I strongly dislike strict mode, and wouldn't ever recommend people use it.

writing things like:

if(Test-Path variable:local:Foo) { ... }
if($HashTable.ContainsKey("Property") -and $HashTable.Property) { ... }

Instead of

if($local:foo) { ... }
if($HashTable.Property) { ... } 

drives me crazy, and makes code less readable.

I know that I'm in the minority among former static language users, but I feel like strict mode is like coding with gloves on.

Having said that, I would not go so far as to recommend against using it within a module (I would recommend against using it at the console), but because it affects child-scopes, you should be cautious when using it, as it can affect other people's code if you're using it and importing other modules.

[Jaykul]

The real question is, should we even care?

The style guide rules focus on readability, to which StrictMode is tangential at best, detrimental at worst.

The best practices focus on readable code, faster code, and coding practices that help you avoid shooting yourself in the foot...

In my personal opinion, a language StrictMode should be about helping you to develop good habits. It's important to realize that PowerShell's strictmode is not a parsing mode, it's a runtime mode.

Instead of forcing you to initialize variables, it causes you to test for them in strange ways.

Additionally, rather than forcing you to test for things (like uninitialized variables), it allows you to rely on strict mode to cause an error (which you can "handle").

In other words, rather than forcing best practices, it forces you to write less readable code, and can even become a crutch where you skip testing for empty/unintialized variables (because you assume they'll blow up if they're empty). This impedes readability (the implied test is invisible) rather than improving it, and doesn't actually improve the quality of your scripts.

Personally, I'd prefer static analysis to point out the problems which StrictMode attempts to address.

Further -- there doesn't seem to be any documentation of changes to StrictMode post -version 2 ... which means if we were to recommend it, you'd need to actually recommend against using -Version Latest, ever...

[dlwyatt]

FWIW, I can't think of any situation where I've needed to test for a variable's existence, rather than its value. Strict mode can help with identifying bugs that come from typos in your variable names (though I rarely have that problem since I compulsively tab-complete everything. :) )

[Jaykul]

@dlwyatt Your lack of imagination is not my problem ;-)

There are plenty of commands like Invoke-WebRequest and Invoke-RestMethod which take a variable name and initialize it rather than taking a [ref] variable. I don't know why they do that (it seems like a design flaw and counter to best practices to me), but regardless ... after calling a cmdlet like that, you could test for -eq $null or test for the existence of the variable -- if you're not in strict mode it makes no difference, but in strict mode it suddenly matters.

Another case is when you're using preference variables like $OFS which by default are not set.

[MartinSGill]

@Jaykul I strongly disagree with your assertion that:

The style guide rules focus on readability, to which StrictMode is tangential at best, detrimental at worst.

While that is a valid opinion, and I agree with much of what you say from a convenience point of view, that doesn't strike me as a true summation of the purpose of this guide.

From this repo's Readme:

PowerShell Best Practices are what you should usually do as a starting point. They are ways of writing, thinking, and designing which make it harder to get into trouble.

Set-StrictMode absolutely makes it "harder to get into trouble". Readability for me also includes having to read code during code-reviews; especially where not everyone contributing to the script has as much PS experience as some others.

Was this a deliberate use of "funky feature" or was it a mistake? Were all possible cases considered etc.; at it's simplest this means always ensuring what you request is actually there.