What does adding `[CmdletBinding()]` above the param block of a PowerShell function change about how that function behaves?

## Simple functions and advanced functions PowerShell has two grades of function. A **simple function** is what you get by default: it takes arguments however they arrive, exposes nothing beyond the parameters you declared, and collects anything it did not recognise into the automatic variable `$args`. An **advanced function** is a function the engine treats as though it were a compiled cmdlet, and the switch that promotes one to the other is the `[CmdletBinding()]` attribute placed immediately above the `param` block. ```powershell function Get-Widget { [CmdletBinding()] param( [Parameter(Mandatory = $true)] [string]$Name ) Write-Verbose "Looking up $Name" [pscustomobject]@{ Name = $Name; Found = $true } } ``` The attribute must sit with a `param` block. `[CmdletBinding()]` followed by `param()` — empty parentheses — is legal and is the correct way to write a parameterless advanced function; the attribute on its own without any `param` keyword does nothing. ## What you inherit: the common parameters The most visible effect is that your function suddenly accepts a set of parameters you never wrote. These are the *common parameters*, and they include `-Verbose`, `-Debug`, `-ErrorAction`, `-ErrorVariable`, `-WarningAction`, `-WarningVariable`, `-InformationAction`, `-InformationVariable`, `-OutVariable`, `-OutBuffer` and `-PipelineVariable`. This is not cosmetic. `Write-Verbose` inside a body writes nothing by default, because `$VerbosePreference` is `SilentlyContinue`. When the caller adds `-Verbose`, the engine raises the preference for the duration of that call, and your verbose lines appear. Without `[CmdletBinding()]` there is no `-Verbose` to pass, so instrumentation you wrote is unreachable unless the caller mutates a global preference variable — which affects everything, not just your call. The same argument applies to `-ErrorAction` and `-WarningAction`: they give the caller per-invocation control over how your function's non-fatal output behaves. ## What you give up: `$args` and sloppy calls Advanced functions do not have `$args`. Every argument must bind to a declared parameter, positionally or by name, and anything left over is a binding failure: ``` Get-Widget -Name 'gear' -Colur 'red' # A parameter cannot be found that matches parameter name 'Colur'. ``` In a simple function that typo would have landed in `$args` and been ignored, and the function would have run with the wrong intent and no complaint. Strict binding is one of the strongest reasons to use `[CmdletBinding()]` on anything other people call: it converts a silent wrong result into a loud failure at the boundary. ## `$PSCmdlet` and the attribute's arguments Inside an advanced function you can use `$PSCmdlet`, the runtime object representing the invocation. Its most-used members are `ShouldProcess()` and `ShouldContinue()` for confirmation, `ParameterSetName` for branching on which set bound, and `ThrowTerminatingError()`. `ShouldProcess` only works if you opt in through the attribute: ```powershell [CmdletBinding(SupportsShouldProcess = $true, ConfirmImpact = 'High')] param( [string]$Name ) ... if ($PSCmdlet.ShouldProcess($Name, 'Remove')) { # do the destructive thing } ``` That single argument adds `-WhatIf` and `-Confirm` to your function for free. `-WhatIf` makes `ShouldProcess` return `$false` while printing what *would* happen, which is the standard way a PowerShell tool offers a dry run. `ConfirmImpact = 'High'` makes the function prompt by default when `$ConfirmPreference` is at its default of `High`. Other useful arguments: `DefaultParameterSetName` names the set to use when the binder cannot tell from the arguments alone; `PositionalBinding = $false` forces every parameter to be passed by name, which is a good discipline for functions with many parameters. ## What it does *not* do `[CmdletBinding()]` does not by itself make your function accept pipeline input — that comes from `[Parameter(ValueFromPipeline = $true)]` on a parameter, together with a `process` block to handle each item. It does not validate your parameters — validation attributes such as `[ValidateSet()]` and `[ValidateNotNullOrEmpty()]` are separate. It does not change what your function outputs. And it does not turn `Write-Error` into an exception; how errors behave is governed by the error-handling machinery, not by the attribute. A related attribute worth knowing is `[OutputType([string])]`, which declares the type your function emits. It is documentation for tooling and tab completion — the engine does not enforce it. ## The practical rule Use `[CmdletBinding()]` on any function that will live longer than the current prompt. It costs one line, gives callers the standard control surface they already expect from built-in commands, and makes bad calls fail immediately.