Here are few tips on scripting I’d like to share. Some of them are inspired by the entries for first Scripting Games event. Some of them are just related.

Before I start the rant please keep in mind I understand criticizing is a lot easier than writing the script and making it awesome. Good luck with the next event!


Use variables and name them properly. Variables are an easy way to label the data you work with. There are few things to focus on:

  1. Do you use the same data on more than one place? Use variable. This especially holds true for the beginner track. The scripts I saw, often sacrificed the readability and maintainability to make the solution a one liner. Here is a little trick that may help you define a variable and still keep it a one liner: ( $source = ‘C:\temp’ ) | Get-ChildItem or even Get-ChildItem -path ( $source = ‘C:\temp’ ). The $source variable is set and the value is also passed to the next command through pipeline. Bit dirty but still better than nothing.
  2. Does the variable name say enough about the data? Variable names like $errVar, $n, $data, $temp or $creDate do not. Tell me more about what is happening, don’t make me guess.


  1. No aliases.
  2. Full parameter names.
  3. Use standard PowerShell naming convention: Verb-SingularNoun. Run the Get-Verb cmdlet and choose the right verb from the right category. Choosing the “Move” verb for the first event was imho optimal.
  4. Don’t get crazy with the noun part, no Archive-ApplicationLogFileToNetworkShare please.
  5. Try to keep your parameter names as standard as possible. Source, Destination, ComputerName, Name etc. If you are in doubt look at the standard commands and follow their lead.


  1. Use whitespace to group related commands.
  2. Break lines after pipeline. There is no need for ` in this case.
  3. You won’t get many points for speed. Read the script few more times. Ask your peers for a review to make the script as easy to understand as possible.


  1. Please do not use too many nested if conditions. I consider three a good maximum. More than that and you make me struggle to understand what is going on.
  2. The correct path should be easy to follow. Put the “everything is going OK” path in the “if” part and the errorneous part in the “else” part.
  3. Don’t use the “$something -eq $true” or “$something -eq ‘True’”. You may slip and write “Treu” instead, resulting in an unnecessary error. Use just “if ($something) {}” instead.
  4. On the other hand if you are testing if something is zero use “-eq 0″.
  5. I know using “!” instead of “-not” is possible but I like the latter better.


  1. Before commenting anything consider if you should comment or if you should use the Write-Verbose
  2. cmdlet instead. I personally use comments to mention the reason why I do the stuff the way I do it. And the Write-Verbose to inform the user about what is happening.
  3. I did not see any usage of Write-Debug. And that is maybe for the better, maybe little too much detail for the event posts.

Inline help

  1. On the advanced track the inline help is kinda mandatory. But if you choose between perfecting the code and perfecting the inline help please choose the code.

Input validation

  1. There is no need to validate an integer parameter for range that is 0 to [int]::MaxValue. It is done by default.
  2. The validating script “Test-Path -Path $_” is a clever way of validating the input path, but keep in mind it will return true even if you provide registry path for example.

Error handling

  1. Most of the people struggled with this.
  2. Forcing stop ErrorAction on a cmdlet, capturing the exception in the catch block and then writing just its message is not the way to do it.
  3. I saw a lot of comments saying there is no error handling because there was no try catch block. I don’t think this is the correct way to look at error handling.
  4. This needs a separate article. :)