The global case of using variables

Question

I have several scripts and modules that use global variables for several things. My journal can take one of three forms; Terse, Verbose and Validation (Verbose logging without actual actions, just checking the data provided). I also have a number of functions that react differently depending on the Context in which they are executed (User or machine), and the action performed (Rollout, Remove, Conform, Relocate) also affects things. So, so far I have used three global variables, and it worked, but I know that the best practice is to avoid global variables. However, the only way to access it is with some Get and Set functions in the same module and Script-level variables. It seems to add complexity without paying much attention, since I still have variables that are in a higher scope than the function using them. Alternatively, I could pass these three values ​​to each function that they need, but it is also a lot of arguments that are of little value. So I'm starting to wonder, is this one place where global variables really are the right answer? Their existence suggests that there should be some kind of situation when they should be used, and this begins to be felt in just such a situation.

Answer 1

There is nothing wrong with using global variables in specific scenarios, especially for global settings or singleton objects that are defined once and then used throughout the rest of the code without further modification. The main thing is to avoid changing variables.

What you need not to use global for variables is state transfer, i.e. change of values. If you change the value of global variables in different places in your code, troubleshooting problems become a huge pain from behind, because you pass information outside of the usual "channels" (parameters, return values). If you need to change a global variable somewhere in your code, it is almost always a sign that you should reevaluate your architecture.

Answer 2

Avoiding Global Variables in PowerShell Using Dynamic Coverage

PowerShell implements Dynamic Scaling . These days, this is a rare choice in the design of languages, but correctly applied dynamic scaling gives the developer much better control over name conflicts than global variables. To understand how this applies to your case, let's look at the following toy module:

# File Module1.psm1 $module = "Module1" $Context = "User" function Log-Message( $message ) { Write-Host "$module/${action}: $message ($LogLevel-$Context)" } function CommonCode { Log-Message "In CommonCode" } function Invoke-Rollout( $LogLevel = "Terse", $Context=$script:Context) { $action = "Rollout" CommonCode } function Invoke-Remove( $LogLevel = "Terse", $Context=$script:Context) { $action = "Remove" CommonCode } function Set-Module1( $Context=$script:Context ) { $script:Context = $Context } Export-ModuleMember -Function Invoke-Rollout, Invoke-Remove, Set-Module1 

The important thing is that in Log-Message variables $module , $action , $LogLevel and $LogContext are not global variables, instead they are free variables, not yet defined. At run time, PowerShell will dynamically determine its binding based on the most recent definition in the call stack ...

Instead of trying to explain it in detail, you might be best off playing with this toy module and see what affects the dynamic definition of the logging area. Here are some experiments I tried:

 PS C:\temp> Import-Module -Force .\Module1.psm1 PS C:\temp> Invoke-Rollout Module1/Rollout: In CommonCode (Terse-User) PS C:\temp> # For Sticky Change -- Set-Module1 PS C:\temp> Set-Module1 -Context Machine PS C:\temp> Invoke-Rollout Module1/Rollout: In CommonCode (Terse-Machine) PS C:\temp> Invoke-Remove -LogLevel Verbose -Context XXX Module1/Remove: In CommonCode (Verbose-XXX) PS C:\temp> Invoke-Remove -Context User Module1/Remove: In CommonCode (Terse-User) PS C:\temp> $Context = "FooBar" # This should have no effet on Module1 PS C:\temp> Invoke-Remove Module1/Remove: In CommonCode (Terse-Machine)