I come from an object-oriented programming perspective, and one thing I cling to even in the fluid world of scripting is strong typing. That's part of what I dig about PowerShell--you can strongly type variables if you want to, or skip it if you don't.
I also try to be fastidous and thorough in declaring functions. I use param blocks instead of in-line parameters, and decorate the input variables with applicable attirbutes like Mandatory, Position, and ValueFromPipeline. For example:
function Format-ValueList()
{
[CmdletBinding()][OutputType([string[]])] param( [Parameter(Mandatory=$true,ValueFromPipeline=$true,Position=0)][AllowEmptyString()][Object[]]$InputObject,[Parameter(Mandatory=$false)][string]$Separator=",",[Parameter(Mandatory=$false)][string]$Delimiter="",[Parameter(Mandatory=$false)][int]$ItemsPerLine= 5 )# The function body...
I include the function-level attributes like CmdletBinding and OutputType because they are described in the PowerShell language specification. But honestly, they don't seem to doanything. Any function with a begin, process, and / or end block will function like a commandlet regardless of whether it has the CmdletBinding attribute, and adding the attribute to a function that has no begin, process, or end block will not cause an
error.
And regarding the OutputType parameter, as I have flagged in the title of this post--it also seems to be ignored. For example, the following works just fine:
function Bait-AndSwitch {
[CmdletBinding()][OutputType([System.Data.OleDb.OleDbConnection])]param([Parameter(Position=13)][string]$AString)return 1,2,3,"No OleDbConnection here",5
}
Bait-AndSwitch 14
So, are these attributes things that the PowerShell development team just never actually implemented, or what? I should note that some parameter-level attributes, such as ValueFromPipeline, Position, and Mandatory do work and are very helpful.
jmh