You say PowerShell braces, I say PowerShell assignments

I am very gratified with the increasing traffic this blog is receiving from a series of posts that describe how to automate tasks in EC2 in AWS with PowerShell. You can see them all here.

As with any creative activity involving language, style is both personal and important. I’ve been getting the impression as I read others’ posts that explain their PowerShell techniques that experienced PowerShellers prefer brevity.

I don’t. Especially for object definitions. Objects (and the pipeline) are at the heart of PowerShell. And I think one should respect those facts by being as detailed as possible when using objects.

Consider the following two snippets. First a terse form of the AWS cmdlet Get-EC2Tag:

Get-EC2Tag -Filter @{ name = "tag:MyCustomTag" ; Values = "*" }

And here’s an alternative:

$tag = New-Object Amazon.EC2.Model.Filter
$tag.Name = "tag:MyCustomTag"
$tag.Values = "*"

Get-EC2Tag -Filter $tag

They produce the same result: a listing of all EC2 objects with the tag MyCustomTag. But, IMHO, the second is vastly superior because it is more explicit.

On the ‘Net you see both styles, but the first form seems to be more prevalent.

There’s no question that it takes more typing in the second form — but I think the long-term value for those extra keystrokes is in the immediate understanding one gets from seeing the exact object being created. The second form makes it clear we are creating an input object for the call to Get-EC2Tag. I also think the assignments to the object’s properties are clearer.

I doubt Scripting Guy Ed Wilson would agree — his amazingly useful PowerShell examples are always as terse as possible. Wilson’s PowerShell book (my first text — and it should be yours, too) goes to great lengths to introduce aliases and to encourage compact expression.

It may be a case of me saying toMAHtoe when everyone else is saying toMAYtoe. But longer, more explicit scripts are a sweeter piece of fruit.