Using PowerShell Splatting to Keep Scripts Clean and Dynamic

The problem: repetitive parameter lists

When you call a cmdlet many times with the same set of options, the command line becomes hard to read and easy to mistype.

What splatting does

Splatting lets you store parameter names and values in a hashtable (or any IDictionary) and pass them to a command by prefixing the variable with @ instead of $. PowerShell treats each key as a parameter name and each value as its argument.

Worked example: conditional recursion

# Base options that are always needed
$base = @{
    Path   = 'C:\Logs'
    Filter = '*.log'
}

# Decide at runtime whether to recurse
if ($NeedRecurse) {
    $base.Recurse = $true
}

# Call Get-ChildItem with the splatted hashtable
Get-ChildItem @base

If $NeedRecurse is false, the hashtable lacks a Recurse key and the command runs without recursion; if true, the key is added and recursion is enabled.

Trade‑offs and limitations

• Duplicate parameters cause a binding error: supplying both -Name 'explicit' and @{ Name = 'splatted' } fails.
• Splatting works only with named parameters; you cannot replace a purely positional argument list unless the hashtable keys match those parameter names.
• Values are evaluated when the command runs, so changes to the hashtable after the call do not affect that invocation.
• Plain‑text secrets stored in the hashtable stay in process memory; for credentials use a secret‑management module such as SecretStore.

You can verify a splatted call by checking the output: run the snippet above in a PowerShell console and confirm that Get-ChildItem returns the expected files, with or without sub‑directories depending on $NeedRecurse.

When to reach for splatting

Use splatting when you find yourself repeating the same parameter set, need to add or remove options based on logic, or want to improve readability of long cmdlet invocations. Keep the hashtable scoped to the call, avoid storing secrets in plain text, and always test for duplicate keys before invoking.