Microsoft created Strict Mode for PowerShell to enforce the use of coding best practices. It’s possible to compose scripts without Strict Mode, but it offers certain advantages when used.
In this article, I explore the benefits and the downfalls of using Strict Mode. Keep reading to find out more.
Working with Strict Mode
Strict Mode is a tool that requires you to declare variables before you use it in a PowerShell script.
Usually, if you use a variable without declaring it first, PowerShell will treat that variable as null or as having a value of 0, depending on the variable type. When you enable Strict Mode, PowerShell won’t automatically set variables to null, and that will cause an error if you try to use an undeclared variable.
If you look at the figure below, you can see that I hadn’t enabled Strict Mode, so I was able to call a previously undeclared variable. PowerShell didn’t return any data because the variable was null, but it didn’t produce an error either.
Undeclared variables may confuse people working on the script. They don’t clarify the intended behavior. You also can’t know if these variables exist or not. Strict Mode helps you remove/reduce the chances of confusion if many people are working on your script.
When you enable Strict Mode, you have to specify a version. The version essentially determines what rules and best practices PowerShell will enforce. This mode currently has three versions. Let’s look at them, starting with the first, the least restrictive one:
Version 1.0
As you’ve probably already guessed, Version 1.0 forces variables to be declared before you can use them.
Looking at the following figure, you can see that I’ve enabled Strict Mode with the Set-StrictMode cmdlet and set the version number to 1.0. If I then try to output the contents of the undeclared $B variable, I receive an error.
Version 2.0
Strict Mode Version 2.0 also enforces the use of variable declaration. In addition, PowerShell also sets some rules about function calls.
When you call a function expecting multiple parameters, Microsoft expects you to provide the function’s name and the variables you want to pass to the function. If, for example, I tried to pass variables $A and $B to a function named Run-MyFunction, then the “correct” way of doing so would be to use this command:
Run-MyFunction $A $B
Even so, this isn’t the only format that PowerShell accepts. If I turn off Strict Mode, I could make the same function call using this command:
Run-MyFunction ($A, $B)
Yet, Version 2.0 won’t allow parentheses and commas in function calls.
Version 3.0
Version 3.0 adds additional requirements. Namely, you can’t call an out of bounds array position. Take this command, for example:
$A=@(1,2,3,4,5)
This command creates a five-position array named $A. The one is in the array’s zero position, and so on. Two takes one’s position, three takes two’s position, four takes three’s, and five takes four’s.
So now, let’s pretend that I want to check an array position to see if it is equal to the contents of $B. For demonstration’s sake, I’ll set $B=5.
If I were to type $B -eq $A[1], PowerShell would evaluate the expression in the usual way. Then, it’ll return a value of False because $B=5 and $A[1]=2.
Similarly, if I were to type $B -eq $A[4], PowerShell would return a result of True because both values are equal to 5. If I type $B -eq $A[5], PowerShell would give me a message about an error. It’ll tell me that the expression is out of bounds. Take a look at the figure below, for example.
You’re probably wondering: Is that really necessary?
Do You Really Need to Use Strict Mode?
Do you need to use Strict Mode in your PowerShell scripts? It depends on your answer to these two questions:
- How likely is it that you’ll need to modify the code in the future?
- What are the odds of someone else having to modify the code?
If you’re trying to create a one-off script that nobody else will mess with, you’re probably fine without Strict Mode. If, on the other hand, you or someone else will be making changes to the script in the future, then it probably makes sense to adhere to good coding practices.
Pro Tips
- Use the Set-StrictMode cmdlet to enable this mode in your PowerShell session.
- Find the Version parameter to select what rules to enforce.
The Bottom Line
When it comes to developing scripts (or any code), code authors have a list of best practices they should follow. In many cases, nothing forces you to use these guidelines. You are free to code as you see fit for the most part.
In this article, I explained how you could use Strict Mode to force the adoption of better coding practices within PowerShell.
I showed you how, practically speaking, turning on Strict Mode forces you to declare your variables upfront and how Versions 2.0 and 3.0 also add extra functionality. While the requirement to declare variables before use might seem insignificant, it can make a script easier to debug.
I tend to think of Strict Mode as a starting point rather than an ending point because it usually means that PowerShell developers adopt some additional coding practices.
Do you have more questions about Strict Mode? Read the FAQ and Resources below!
FAQ
Can I disable Strict Mode once I turn it on?
When turning Strict Mode on, you must use the Set-StrictMode cmdlet with the -Version parameter and the desired version number. If you want to turn Strict Mode off, use the Set-StrictMode cmdlet, but replace the -Version parameter with -Off (you don’t need a version number).
What scopes are affected when you turn Strict Mode on?
When you enable Strict Mode, it only applies to the current scope and any child scopes. Additionally, Strict Mode only runs during current sessions. If you open a different PowerShell window, Strict Mode won’t work unless you turn it on.
What are some PowerShell best practices?
PowerShell scripting has many best practices. In a nutshell, do your best to make the code easy to read. This means using meaningful variables and function names and making use of comments. Enabling Strict Mode in some PowerShell sessions may also help you adhere to these guidelines. It’ll force you to use only declared variables.
Can Strict Mode make it more challenging to develop PowerShell scripts?
Those new to PowerShell might find that Strict Mode requires more effort, particularly when resolving errors. Once you gain a little bit of experience, it becomes a lot easier to recognize an error caused by a Strict Mode violation.
Will Strict Mode ever have a Version 4.0?
Only Microsoft knows for sure, but it seems likely that Strict Mode will extend in the future. Microsoft creates new PowerShell versions regularly, so Microsoft may update Strict Mode as PowerShell evolves.
Resources
TechGenix: Tracing Your Way Through PowerShell Scripts
Learn how to trace your way through a complex PowerShell script here.
TechGenix: PowerShell Wet vs. Dry Scripting
Read more on PowerShell’s wet and dry scripting techniques here.
TechGenix: Scripting Resources from PowerShell
Find out how to find more great scripting resources in the PowerShell Gallery here.
Microsoft: Set-StrictMode cmdlet
Find the documentation for the Set-StrictMode cmdlet here.
Microsoft: Better Scripting Practices
Read more about using Strict Mode to enforce better scripting practices here.
Microsoft: Find out if Strict Mode Is On
Learn how to programmatically find out if Strict Mode is enabled here.
I’ve put
Set-StrictMode -version Latest
in my profile – it forces me to behave even when I’m building little one-off one-liners at the command line. This gets me in the habit of making sure I’m doing things right when I build scripts.