Event 1: my notes.

Scripting Games is chance to learn things. You can learn by good example, or by mistakes, but often – mistake for one person is perfect solution for other. In PowerShell there are usually many ways to skin the cat, some of those I like – some, not so much. So what did I like and dislike so far? Here are few notes I made.

Beginners – likes

Let’s start positive. What I liked? Well, not hard to guess that I liked when people used similar techniques I would use. I must say I’m impressed with some approaches. I especially liked idea to create folder in script block passed to –Destination parameter that I’ve seen in one of entries. As you probably know New-Item (or any other command that you would want to use instead, like mkdir function) returns object. And fits perfectly as value for –Destination:

Get-ChildItem *.log | Move-Item -Destination { mkdir Test }

Original was obviously using value of input file to decide what destination folder’s name should be. Also – use of –Force made it all possible.

Another smart idea I’ve seen was using Select-Object to pre-calculate values for parameters:

Get-ChildItem Log\*\*.log | select @{            
    Name = 'Destination'            
    Expression = {            
        "\\NASServer\Archive\{0}" -f $_.Directory.Name            
    }            
}, @{            
    Name = 'Path'            
    Expression = { $_.FullName }            
} | Move-Item -WhatIf

I’ve seen also many people using Join-Path and Split-Path – way better in my books than manual building your paths. It’s true for almost any provider, including ActiveDirectory Provider:

Set-Location AD:\               
Join-Path -ChildPath OU=Test -Path 'DC=monad,DC=ps1'            

No need for concatenating strings here. Finally – I liked when people used well-known tools. I truly believe that Shell in the name of my beloved product is there for a reason. On the other hand: if you want to use built in tools (like robocopy) – don’t hesitate and stop in the middle. Why not:

Robocopy.exe .\Log .\Arch *.log /MIR /MOV /MINAGE:90            

Finally – using format operator. I really like this technique, because it separates form and data. If you ever decide to change data – you don’t have to mess up with form. It also makes it easier to use properties – no need for sub-expressions, you just “inject” value into string:

$Name = 'PowerSheller'            
'Welcome, {0}' -f $Name

Beginner – dislikes

The thing that I’ve seen as worse “sin” was the fact that some attendees made things worse with their script. Scenario informs us about lack of space, and they copy files rather than move old logs. In this world “works” is most important. If you only copied files (without removing them afterwards at least) than in my opinion nothing will make your script look good.

Code-wise the worse thing I’ve seen were wanna-be-one-liners. From code perspective it was obviously not even close to one-liner. Heck – even one-liner, when written for others to read, can be broken into several lines! But if you have several statements separated by semicolon all in one loooong line – you are doing it wrong. Seriously.

Another issue was repeating code. I’m not fan of any kind of code that is (almost) same thing repeated three times. PowerShell supports looping constructs very well, use them for your advantage rather than copy&paste in your editor of choice.

Finally: .NET. Especially frequent usage of .Replace, .Split, .Substring. – really, there are better ways for working with paths than $Path.Split(‘\’)[-1]. If there is cmdlet – try to use it. Use .NET when it’s quicker and obvious like (Get-Date).AddDays(), or necessary.

Advanced – likes

I must admit, I’m very happy with most of the scripts I’ve seen so far. Comment based help is almost always there. Parameters are very often validated (however sometimes I’ve seen some validations that are not needed or won’t work, like [ValidateNotNullOrEmpty()] for integer). Most of scripts use [Parameter()] to get mandatory parameters, or define parameters that are working with pipeline. Also error handling was very good most of the time – I especially liked use of –ErrorVariable parameter and creating own error variable rather than using built in $Error. Using pipeline is also usually very good.

People don’t forget about reusability and try to build functions, however this tasks was relatively “closed” and single function would probably suffice.

Another good thing is that most of the scripts favor Write-Verbose and Write-Debug rather than Write-Host. This is very important especially in PowerShell v3 where former can be redirected to standard output, and latter – can’t.

And finally – something I wrote separate blog post about: usage of WhatIf and Confirm. I really feel that it has to be implemented rather than just enabled. You really shouldn’t leave it for cmdlets to pick up. Some people did it and they got on my favorite list (unless they did something else that made me change my mind. )

Advanced – dislikes

Most of the issues I’ve mentioned in part related to beginner category are true for some scripts written in advanced category. What else? List goes on, so fasten your seat belts…

I’m naming-police (in heart, haven’t got any ID or anything else to prove it). So if you violate Three Rules of Command Naming – you are in trouble. First of all, name has three parts: verb, hyphen, noun. There are some exceptions to it, but I hardly believe your function is exceptional enough to join that group. Second: verb has to be approved. Backup is not approved verb. Neither is Archive. On top of approved verbs there are also other rules involved, but I won’t go that far. If your verb is approved – it’s fine. If you want to have some tips what verb should you choose – take a look at MSDN doc. Finally – noun. What command do you use to get all processes on your box? Get-Process. And services? Get-Service. So how would you name function that moves some files? If your answer is: “Move-SomeFiles”, start over from “Finally – noun”. Repeat.

Next thing is oh-so-famous “if” and comparing boolean to boolean. Why do I think it’s bad? Because $true –eq ‘False’. And because “if” is working on booleans. You already have one, so why would you compare it to anything? if (Test-Path) {} will just work. No need to compare result of this command to $true or $false. If you want to reverse it – just use –not and you are good to go. And if you start comparing booleans to strings, you are asking for troubles.

Another issue I’ve seen is writing scripts that validate parameters. Why would you write your own validation logic, when everything you need is probably there already? Add [Validate*()] to your parameter definition and you are done with it. You won’t have to work hard on friendly error messages. They are built in and consistent. Use them.

On that note: when you use them, be aware that you have no access to other parameters being validated. If you check value of other parameter – you are either looking at not-existing variable, or variable defined in parent scope. If user will pass different value you will only have false negatives or false positives. Either is bad, if your code relies on the condition used.

I also seen script where author was doing #requires –version 3.0 on his own. While this is not something crucial and hand-made solution will work, I really feel that using built-in features is not only easier, requires less work, but is also consistent. Error message makes it clear why given script won’t work on current box.

Next topic can be explained in single word: aliases. If you don’t know why is bad, try to read some really cryptic examples written by others. And imagine you have to modify script you wrote at 3AM, in the middle of the fire.

Finally, something I’ve seen only once, but I must mention it. Being CLI person I really can’t see any value in script that forces me to pass parameters using GUI. If you want GUI – no problem, design one. But if you want to make it reusable tool, make sure people who don’t love mouse so much can simply call your script with inline parameters. Unless, obviously, script is designed with GUI in mind (like picture browser). And that would be it. Pretty long list, but don’t get me wrong: I still think that scripts are pretty good overall. Just not flawless.