Global or Passed vars?

Question

I have a situation where I am going to process a series of "Packages" which contain an arbitrary series of "Tasks" and I need to then write that info to the registry in a "Package" Key and "Task" Values. The actual
Package and Task processing happens with For Each loops.
I can see two ways of doing this.
1: A global variable $CurrentPackage, and the end of Process-Task writes to .../$CurrentPackage/$Task
2: No global variable, $Package is passed as a string to Process-Task along with $Task.
I have some other similar situations, so I am curious if there are any general best practices on use of Global vars vs passing more info to Functions. Also, when using global variables, is it best practice to name them so that scope is obvious? In VBScript
I used G_strName or the like to make scope obvious. But PowerShell seems to dispense with most nomenclature beyond overall use of the variable. 
Thanks!
Gordon

Answer 1

The simplest way to handle that is to have your logging module export a variable in addition to its functions. When you do that, the variable exists in the Global scope where callers can modify it, but when they do change it, they're actually setting it
in the module's Script scope (so all of its functions can read it without any issues.)
I use a different approach for logging in my own scripts. I've got this module posted on the Gallery:
http://gallery.technet.microsoft.com/Enhanced-Script-Logging-27615f85 , which automatically intercepts any text that was going to be displayed at the console (regardless of
how it got there; no need to funnel things through a specific command like Write-Log.  Also covers Verbose, Error, Warning and Debug output.)  To turn logging on, I just add this command to the beginning of a script:
$logFile = Add-LogFile -Path '<Path to my log file>'
After that, the script doesn't even have to be aware that it's producing a log file.  The code is just the same as if you were displaying everything at the console.
Regarding the $LogFile "preference" variable topic, when your module exports a variable it automatically becomes accessible to both the caller and the module, but the built-in Preference variables ($ErrorActionPreference, etc) do not.  That's a little
quirk of how Script Modules work; they have their own SessionStates and their own variable scope stack.  I recently figured out how to work around this, and have posted the Get-CallerPreference function on the gallery as well: 
http://gallery.technet.microsoft.com/Inherit-Preference-82343b9d
Now, I just add this command as the first statement in any exported script module function:
Get-CallerPreference -Cmdlet $PSCmdlet -SessionState $ExecutionContext.SessionState
It checks whether any of the default preference variables are set in the caller's scope, and if they are, it sets them locally.  At that point, you're good to go; any helper functions in the module will automatically inherit those variables from your exported
function's scope.  This only works for Advanced Functions with the CmdletBinding() attribute (or at least one Parameter() attribute) set, but basically all functions should be using that these days anyway.