Looking for a PowerShell code review before releasing a console formatting library
September 9, 20263 answers
Asked byMellowQuartz47
I'm preparing a lightweight PowerShell console presentation and layout library for its first stable release and would appreciate constructive feedback from experienced PowerShell users. I'm especially interested in idiomatic PowerShell, parameter naming, error handling, PowerShell 7 compatibility on macOS and Linux, and better ways to implement the existing functionality. I'd like to catch breaking changes before version 1.0.0.
The library is designed for readable console output in interactive automation scripts such as installers and cleanup tools. It should complement full logging frameworks rather than replace them, remain easy to dot-source, support PowerShell 5.1 and newer, have no dependencies, and sit between basic formatting utilities and larger console UI toolkits.
For this release, the functions are not pipeline-enabled, stream integration is out of scope, tests use a custom visual-checking script instead of Pester, and the functions do not use CmdletBinding because I'm not yet sure which ones need advanced-function behavior. I'm open to suggestions about these decisions, possible cross-platform issues, and any conventions or design improvements I may have missed.
There are established cross-version formatting options worth examining. A text-rendering module such as Pansies can provide color and styling that works across Windows PowerShell 5.1 and PowerShell 7 on Linux, macOS, and Windows. Its text commands return objects rather than immediately writing to the console, which makes it easier to compose headers, lists, and other formatted sections before sending the result to the host. That approach also enables pipeline-friendly helper functions.
MellowQuartz47: I’ll take a look at that approach. For this library, avoiding dependencies is intentional because sometimes the script and its formatting file need to be copied directly to another machine. That portability requirement is more important for now, even if it means relying on native formatting features available in PowerShell 5.1.
Reply to this answerCedarVale8
A few practical improvements stood out. For full-width separators, consider using `'-' * [Console]::WindowWidth` rather than maintaining a separate width calculation. If this is packaged as a module, use `$script:` for shared state so it stays scoped to the module instead of leaking into the caller’s session. The functions could also live in separate public command files and be combined during a build, which becomes much easier to maintain as the project grows. Finally, use standard PowerShell comment-based help for the functions, including `.SYNOPSIS`, `.DESCRIPTION`, `.PARAMETER`, and related sections.
MellowQuartz47: Those are helpful suggestions. I’m deliberately keeping the raw script format because it’s convenient to copy alongside another script, although I understand that dot-sourcing means script-level state can still enter the caller’s scope. Splitting functions into separate files is new to me, and I’ll look into it for larger projects. I also wasn’t familiar with PowerShell’s comment-based help conventions, so the parameter formatting clarification helps.
Reply to this answerNorthwindMosaic6
Before reviewing implementation details, it helps to define the review goal clearly. In this case, the useful scope is improving the existing code and learning PowerShell conventions—not redesigning the whole library or adding every possible feature. Calling out the areas where you’re least confident should lead to more actionable feedback, such as specific “prefer this pattern instead” recommendations.
MellowQuartz47: That’s exactly what I’m looking for. I’ve worked with software development for a while but have less experience with PowerShell, so I want to use this project to strengthen my fundamentals and learn the idioms and conventions I may have missed.
MellowQuartz47: I’ll take a look at that approach. For this library, avoiding dependencies is intentional because sometimes the script and its formatting file need to be copied directly to another machine. That portability requirement is more important for now, even if it means relying on native formatting features available in PowerShell 5.1.