Master PowerShell Windows Scripting Patterns

A catalog of critical PowerShell syntax pitfalls and their fixes, gathered from real-world errors. Operator syntax requires wrapping every cmdlet call in parentheses before combining with -or or -and, such as if ((Test-Path "a") -or (Test-Path "b")) rather than the unparenthesized form, which PowerShell rejects. Scripts must avoid Unicode and emoji entirely, no checkmarks, red circles, or warning-sign glyphs, using ASCII tags like [OK], [X], [WARN], and [INFO] instead. Null-check patterns require guarding before property access, such as $array -and $array.Count -gt 0, or wrapping $text.Length in an if ($text) check, rather than assuming a value exists. Complex string interpolation should be avoided in favor of assigning the expression to a variable first and interpolating that. Error handling should set $ErrorActionPreference deliberately per context: Stop for fast-failing development, Continue for production scripts, SilentlyContinue when errors are expected, and try/catch blocks should never return from inside try, using finally for cleanup and returning after the block. File paths should use Join-Path rather than string concatenation for cross-platform safety, whether building from $env:USERPROFILE or a script-relative directory. Array operations follow specific idioms: @() for an empty array, += for appending, and .Add() plus a pipe to Out-Null for an ArrayList to suppress the returned index. JSON operations must always pass -Depth, commonly 10, to ConvertTo-Json for nested objects since the default depth silently truncates them, paired with Get-Content -Raw piped to ConvertFrom-Json for reading and ConvertTo-Json -Depth 10 piped to Out-File -Encoding UTF8 for writing. A common-errors table maps four PowerShell error messages directly to their cause and fix: "parameter 'or'" means missing parentheses, "Unexpected token" means a Unicode character slipped in, "Cannot find property" means a null object wasn't checked, and "Cannot convert" means a type mismatch needing .ToString().

Use when writing or debugging Windows PowerShell scripts, especially when hitting one of the four named error messages, working with nested JSON, or building cross-platform-safe file paths. Not for POSIX shell scripting (bash or zsh) or PowerShell Core cross-platform concerns beyond what's listed here - this is specifically a catalog of Windows PowerShell's own syntax quirks.

Input is a PowerShell script exhibiting one of the covered syntax errors or design questions such as operator logic, null safety, JSON depth, or path construction. Output is the corrected pattern plus a reusable script template with strict mode, a deliberate $ErrorActionPreference, and a try/catch/exit-code structure.

### Strict mode
Set-StrictMode -Version Latest
$ErrorActionPreference = "Continue"

### Paths
$ScriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path

### Main
try {
    # Logic here
    Write-Output "[OK] Done"
    exit 0
}
catch {
    Write-Warning "Error: $_"
    exit 1
}

Purely a PowerShell language and cmdlet reference (Test-Path, ConvertTo-Json and ConvertFrom-Json, Join-Path, Set-StrictMode) with no external tool dependencies.

Developers writing or reviewing Windows PowerShell scripts who keep hitting the same handful of syntax traps - missing parentheses, Unicode in output, unchecked nulls, shallow JSON depth - and want the fix pattern on hand rather than re-debugging each one.