Constant and read-only PowerShell variables for admins who fear change

Most people define a variable in a programming language as a placeholder for something else. The variable is a bucket that stuff goes into, comes out of, gets changed and gets removed. However, there’s a certain subset of PowerShell variables that can be defined but can never change. These sets are called constants and read-only variables.

Constants and read-only variables are pretty much functionally equivalent. Values are assigned to a constant or read-only variable, but can never change. In the case of an actual constant, it can’t even be removed. Let’s go over a quick example.

If you’ve written scripts in PowerShell you’ve most likely assigned variables in the form $Variable = 'some value.' This is common practice and is the typical way in which a variable is defined. But there is a built-in PowerShell cmdlet called Set-Variable that can assign variable values as well. It’s not as commonly used because writing $Bucket = 'Full' and Set-Variable -Name 'Bucket' -Value 'Full' are functionally equivalent.

I created that $Bucket variable and assigned it a value of Full. I then changed the value of $Bucket to Empty. But what if I want to create a constant? In that case, use Set-Variable with an additional parameter called Option. By using the Option parameter, admins can assign the $Bucket variable as always being 'Full.'

When changing the value of $Bucket I received a red error text stating that the change wasn’t allowed. The constant cannot be changed or removed.

That’s the gist of constants, but what about read-only variables? The difference between the two is that read-only variables can be removed.

I used Set-Variable again and all the parameters and parameter values were the same except that I used the value ReadOnly instead of Constant for the Option parameter. After assigning the value, I then attempted to remove it and was met with the error again. But the notice said, 'If the variable is read-only, try the Force option.' I then used the Force parameter and was able to successfully remove the variable.

But why would an admin use a constant or read-only variable in the first place? There are a few reasons. One reason to use read-only variables would be when you have a large script that potentially has hundreds or thousands of variable declaration lines. Perhaps you have a variable assigned to an important attribute of a server and throughout that script you’re making multiple changes to other attributes and you want to make sure you don’t accidentally assign a value to that attribute. If that variable is changed some bad things will happen and your script will blow up. Making it a read-only script ensures you don’t mess up.

The same can be said for constants. Constants can be used to solidify a variable’s value and to prevent either accidentally or purposely changing or removing the value. Perhaps the script is being provided to other people and you don’t want them messing with your variable declarations.

Finally, constants are technically better in theory than variables. Defining a constant means you're being more explicit in your intention. You're removing another variable in your script that you must take into account later on down the road. If you want to get really technical, a constant is easier on memory because it doesn’t have to be tracked like variables.