Your team maintains a large shared PowerShell codebase. Would you mandate `Set-StrictMode` together with typed, validated parameters across it, and what does that discipline cost?

## The default that makes PowerShell pleasant also makes it dangerous PowerShell was designed for people typing at a prompt, and interactive ergonomics favour permissiveness. Reference a variable you never assigned and you get `$null`, not an error. Ask for `$user.EmailAddres` when the property is `EmailAddress` and you get `$null`, not an error. Compare that `$null` to something and the comparison quietly succeeds or quietly fails. At a prompt this is fine — you see the empty result and retype. In an unattended script that provisions accounts or deletes resources, the same behaviour means a typo produces a wrong action rather than a stopped run, and the eventual failure appears far from the line that caused it. Choosing a stricter dialect for shared code is therefore a real engineering decision, not a style preference. ## What `Set-StrictMode` actually buys ```powershell Set-StrictMode -Version 3.0 ``` The versions are cumulative: - **1.0** — referencing an uninitialised variable is an error, except inside strings. - **2.0** — adds uninitialised variables inside strings; references to non-existent properties of an object; calling a function using method-call syntax (`Get-Thing($a, $b)`, a classic newcomer bug); and a variable reference without a name. - **3.0** — adds out-of-bounds and unresolvable array indexes. - **Latest** — whatever the newest rules are on the engine that happens to run the code. The non-existent-property rule from 2.0 is the one that catches most real defects, and the method-call-syntax rule catches a genuine class of silent misbehaviour where the arguments arrive as a single array. Two properties of the cmdlet shape how you deploy it. It applies to the scope in which it is called and that scope's children, so it is not a global switch — every script and module must set it for itself, and a file someone adds later without it is silently unprotected. And `Latest` means the rule set can change under you: upgrading the engine can turn previously running code into failing code. For shared automation, pin an explicit version and change it deliberately. ## What typed and validated parameters buy — and what they do not ```powershell function Test-Threshold { param( [Parameter(Mandatory = $true)] [ValidateRange(1, 100)] [int]$Percent, [ValidateSet('warn', 'fail')] [string]$Mode = 'warn' ) "$Mode at $Percent percent" } ``` The important distinction is that a **type annotation coerces**, while a **validation attribute rejects**. `[int]$Percent` does not mean "only integers are accepted" — PowerShell will convert `'50'` to `50`, and it will convert `2.5` to `2` using .NET's round-to-even, which surprises people who expected 3. `[string]` will happily stringify almost anything, so a caller passing an object gets its type name rather than an error. If you want a gate, you need `[ValidateRange()]`, `[ValidateSet()]`, `[ValidatePattern()]`, `[ValidateNotNullOrEmpty()]` or a `[ValidateScript()]`. `[ValidateSet()]` earns its place twice: it rejects bad values *and* it drives tab completion for callers, which is a usability win, not just a safety one. `Mandatory = $true` prevents the silent-empty-parameter class of bug that strict mode does not cover, because a parameter with no value is initialised, just empty. ## The costs, stated honestly - **Idiomatic dynamic code breaks.** Probing heterogeneous objects with `if ($obj.MaybeThere)` is a normal PowerShell pattern and becomes an error under 2.0+. It has to be rewritten with `$obj.PSObject.Properties.Name -contains 'MaybeThere'`, which is more correct and less readable. - **Coverage is per-file and easy to lose.** Because the setting is scoped, there is no single place to enforce it; you need a lint rule or a template. - **Version sensitivity.** `Latest` can shift behaviour on upgrade; a pinned version can lag behind useful new checks. Either way it is a decision someone must own. - **Rigidity at the boundary.** Tight validation on a widely called function makes every legitimate new use case a change to the function. That is usually the right trade, but it is a trade. - **Migration cost.** Turning strict mode on across an old codebase surfaces latent bugs all at once, at a time you did not choose. ## How I would actually roll it out Mandate it for new scripts and modules and for any file being substantially changed, rather than as a flag day. Put `Set-StrictMode -Version 3.0` in the file template so nobody has to remember. Run `Invoke-ScriptAnalyzer` in CI so the convention is checked rather than hoped for, and treat that as the enforcement mechanism instead of review comments. Add tests around the paths the migration touches, because strict mode turns silent wrong behaviour into loud failure — which is the point, but only helps if someone is watching when it fires. The underlying judgment is about audience. Code that only its author runs interactively benefits from permissiveness. Code that other people invoke, that runs unattended, or that changes production state should fail fast and loudly, and paying a little expressiveness for that is a good deal.