What you see is NOT what you get.

While grading scripts in advanced category event 4 I noticed that most people assume that it’s necessary to change number into string to format it nicely. The problem with this approach: once you changed number into string you kind of kill PowerShell ability to sort, filter and group objects based on properties that are numbers. If you ever decide to use it for something else than showing to the user – you will probably have to parse results and reverse whole process. And because it’s PowerShell that you use – you do not really have to. You can get both. As advanced scripter – you should know that already. Let’s take a look at some practical examples, to make it more clear when problems start to show up. If I will sort two objects:

2,10 | foreach {            
    New-Object PSObject -Property @{            
        Name = "Foo $_"            
        Size = "$_ Bars"            
    }            
} | Sort-Object -Property Size            

… PowerShell will try to convince me, that 2 Bars are greater than 10. In world of strings that’s true. In world of numbers – not so much. To be honest – for me that’s huge flaw of that approach. It looks nice, but that’s not usually what I’m after. I want PowerShell to give me information first, look nice later. So what could one do?

“Format-{0}”–f ‘List’

Today I would like to write few words about why you shouldn’t work too hard with creating output when PowerShell can do the work for you.

Scripting, as I see it, is a way of taking stuff that “is there” and force it to do my job in a way I want it to be done. If there is something that will do job for me – I will use it. If not – I will create it. So my role is just to build the bridges, not whole road next to the old one.

Obviously, at times you do not know that road already exists. That’s where stuff like Scripting Games help a lot. I for one learned few neat tricks already. But if you fail to see highway and claim to be advanced scripter – be warned, I won’t praise your rocky road that you’ve created next to it. To the point.

Hey! Don’t *break* my pipe!

I’m still pretty overwhelmed with number of scripts this year in Scripting Games. While I’m on my “Mission Impossible” I noticed extensive use of break keyword. I commented on it a lot in Beginner 3, but would like to show you why I do not like this as a way of ending your functions and/ or scripts.

I mean, it’s perfectly fine if you use it with what I will show you today in mind, that is: if you want your function/ script to be destructive and break things when you see an error. But if your function/ script is only getting some info from my system and I won’t get full information (like in Advanced Event 2) without admin rights – why do you break things? Isn’t exit/ return enough in such a case…?

1… 2… 3… Testing…

Scripting Games are in more or less middle. They have been huge success  this year – much more scripts that last year, which is awesome! I was hoping I will be able to grade every script submitted, but at the moment it looks like mission impossible…

Anyway one thing that I would like to highlight today is testing. Seen many entries where single typo made huge difference, including turning 5/4* script into 1* script. And because with PowerShell we got huge power, and with power comes responsibility – testing is more important than ever.