The PowerShell paradigm is the task based cmdlet.  With cmdlets that surface a single function that handle a multitude of inputs, a PowerShell session or script can read back like a sentence. 

Get-Process –Name iexplore | Where-Object {$_.WorkingSet –gt 50000000 } | Stop-Process

In the above (often overused, but illustrates the point well) example, Get-Process, Where-Object, and Stop-Process all accurately describe the task that they perform.

We can take this same approach with our scripts and functions.  By keeping your scripts and functions focused on performing discreet tasks, you keep with the composable nature of PowerShell and provide yourself the most flexibility in reusing the functions you create.

One of the most common “errors” I see in PowerShell scripts that are shared is the embedding of formatting in the output of the script.  If your script generates output, it should be in the form of objects (custom or otherwise).  (The only caveat here is if your script’s functionality is to handle the output of data, in which case it’s sole focus should be the handling that output.)

The PowerShell ecosystem provides a number of tools for formatting the output of your scripts, whether you want to display your scripts in the console window (Format-List, Format-Wide, Format-Custom, Format-Table), as a web page (ConvertTo-HTML), sent to a CSV file (Export-CSV) or XML (Export-CLIXML), in Version 2 to a sortable, groupable grid (Out-GridView), as well as a number of other options (Visifire graphs via PowerBoots, Excel, PDF, or Image via the Reporting Services Redistributable, or as a netmap using NodeXL).

Take advantage of these, or write your own.  If you write your own, it should work with custom objects, to keep with the composable nature of PowerShell.