|
| 1 | +--- |
| 2 | +title: Messaging |
| 3 | +description: "Write-Verbose for user-facing operational progress and normal troubleshooting; Write-Debug for developer-focused internals and deep diagnostics." |
| 4 | +--- |
| 5 | + |
| 6 | +# Messaging |
| 7 | + |
| 8 | +Choose between `Write-Verbose` and `Write-Debug` based on the audience and purpose of the message. This distinction clarifies intent for maintainers, improves discoverability for operators, and keeps diagnostic output focused. |
| 9 | + |
| 10 | +## The rule |
| 11 | + |
| 12 | +- **Use `Write-Verbose`** for **user-facing** operational progress, decision summaries, and normal troubleshooting context — information that helps operators understand execution flow and diagnose issues at the normal operational level. |
| 13 | +- **Use `Write-Debug`** for **developer-focused** internals, deep diagnostics, low-level payload and transport details, internal state, and instrumentation — information for the author and maintainers of the code, not operators. |
| 14 | + |
| 15 | +## Examples |
| 16 | + |
| 17 | +### Write-Verbose: operational progress and troubleshooting |
| 18 | + |
| 19 | +These messages help an operator understand *what is happening* and *why*, without needing to know the implementation details. |
| 20 | + |
| 21 | +```powershell |
| 22 | +# Progress narration — what step is running |
| 23 | +Write-Verbose "Retrieving repository metadata from GitHub..." |
| 24 | +
|
| 25 | +# Decision summary — what the code decided and why |
| 26 | +Write-Verbose "Found 3 matching repositories; filtering to 1 owned by the org" |
| 27 | +
|
| 28 | +# Outcome — what succeeded or failed at the user-visible level |
| 29 | +Write-Verbose "Successfully cloned repository to $DestinationPath" |
| 30 | +
|
| 31 | +# Configuration recap — what settings are in use |
| 32 | +Write-Verbose "Using authentication method: Personal Access Token" |
| 33 | +``` |
| 34 | + |
| 35 | +Verbose messages stay at a **business level**: they talk about repositories, deployments, workflows, API calls — things an operator cares about. |
| 36 | + |
| 37 | +### Write-Debug: internals and deep diagnostics |
| 38 | + |
| 39 | +These messages are for the code author and maintainers. They expose the implementation details that help diagnose why something went wrong *internally*. |
| 40 | + |
| 41 | +```powershell |
| 42 | +# Payload details — the raw data moving through the code |
| 43 | +Write-Debug "Request body: $($RequestBody | ConvertTo-Json -Depth 10)" |
| 44 | +
|
| 45 | +# Internal state — variables and computed values |
| 46 | +Write-Debug "Resolved repository ID to: $RepoID" |
| 47 | +Write-Debug "Cache hit: $CacheHit; items in cache: $($Cache.Count)" |
| 48 | +
|
| 49 | +# Low-level transport details — HTTP headers, raw responses |
| 50 | +Write-Debug "Response header 'X-RateLimit-Remaining': $($Response.Headers['X-RateLimit-Remaining'])" |
| 51 | +
|
| 52 | +# Instrumentation — timing, counters, flow paths |
| 53 | +Write-Debug "Processed $ProcessedCount of $TotalCount items (elapsed: $ElapsedMs ms)" |
| 54 | +Write-Debug "Taking fallback branch: condition was $Condition" |
| 55 | +``` |
| 56 | + |
| 57 | +Debug messages expose **plumbing**: they talk about payloads, headers, cache state, internal variables — details that only make sense in the context of reading the code. |
| 58 | + |
| 59 | +## Review checklist |
| 60 | + |
| 61 | +When writing messages, ask: |
| 62 | + |
| 63 | +1. **Is this message useful at normal troubleshooting level?** ✓ Use `Write-Verbose` |
| 64 | + - Operators should understand it without reading source code. |
| 65 | + - It describes *what* is happening at the business level (workflow, deployment, repository, API call). |
| 66 | + - It helps answer "what did my operation do?" or "where did it fail?". |
| 67 | + |
| 68 | +2. **Is this an internal/deep diagnostic detail?** ✓ Use `Write-Debug` |
| 69 | + - Only a code author or maintainer needs this information. |
| 70 | + - It exposes implementation details (payload, headers, internal variables, timing). |
| 71 | + - It helps answer "why did the code take this path?" or "what is the state inside this function?". |
| 72 | + |
| 73 | +3. **Am I unsure?** Prefer `Write-Verbose` — it's safer to be slightly more verbose at the normal level than to hide troubleshooting context that operators need. |
| 74 | + |
| 75 | +## Enabling messages at runtime |
| 76 | + |
| 77 | +PowerShell controls visibility with built-in preference variables — no code change needed to see messages: |
| 78 | + |
| 79 | +- **Show verbose messages:** run the command with the `-Verbose` switch, or set `$VerbosePreference = 'Continue'` before calling. |
| 80 | +- **Show debug messages:** set `$DebugPreference = 'Continue'` before calling the command (no `-Debug` switch exists; use the preference). |
| 81 | + |
| 82 | +Example: |
| 83 | + |
| 84 | +```powershell |
| 85 | +# Operator runs the command with -Verbose to see operational context |
| 86 | +Get-Repository -Owner 'MyOrg' -Name 'MyRepo' -Verbose |
| 87 | +
|
| 88 | +# Or sets the preference for all calls in the session |
| 89 | +$VerbosePreference = 'Continue' |
| 90 | +Get-Repository -Owner 'MyOrg' -Name 'MyRepo' |
| 91 | +
|
| 92 | +# In a script, enable debug messages |
| 93 | +$DebugPreference = 'Continue' |
| 94 | +Invoke-RepositoryOperation |
| 95 | +``` |
| 96 | + |
| 97 | +## Relationship to other messaging |
| 98 | + |
| 99 | +This standard covers the two main diagnostic channels. For context: |
| 100 | + |
| 101 | +- **`Write-Information`** — user-facing but outside the troubleshooting spectrum. Use it for important operational summaries that should always be visible (not gated by `-Verbose`), e.g., "Migration complete: 42 items processed." |
| 102 | +- **`Write-Warning`** — a condition the operator should know about but that did not stop the operation; reserved for genuine warnings, not verbose narration. |
| 103 | +- **`Write-Error`** (terminating) — a failure that stops execution; emit structured errors with `[PSCustomObject]` or `-ErrorRecord` for discoverability. |
| 104 | +- **Logging (event logs, files)** — persistent audit; separate from these streams and outside the scope of this standard. |
| 105 | + |
| 106 | +Reserve the verbose and debug streams for their intended audiences, and keep messages at the right level so operators and maintainers can both find what they need. |
0 commit comments