Prof. Powershell
To Write Better PowerShell Scripts, Let's Get Back to Basics
Let me offer a few suggestions that will make your script writing easier, more productive and less buggy.
- By Jeffery Hicks
- 08/16/2011
Many people jump into PowerShell and immediately think they need to start writing scripts. That couldn't be further from the truth, and actually I believe that can be counter-productive. Without a doubt the ability to create PowerShell scripts, functions and modules is essential to your growth as a Windows IT pro. But don't just open Notepad and start copying and pasting code snippets from Google or Bing. Let me offer a few suggestions that will make your script writing easier, more productive and less buggy.
First, take time to learn how to use the PowerShell console interactively. Because there is no difference between running a PowerShell script and entering the commands manually at a prompt, if you don't understand how PowerShell works, you won't be able to script.
Next, don't use Notepad to write your scripts. At the very least use the PowerShell ISE that ships with Windows 7. It is not a replacement for a full-scale script editor, but it is an order of magnitude better than Notepad. What I really suggest is that you invest in the best commercial or third-party script editor you can afford. There are many on the market at a variety of price points, starting at free and with a corresponding number of features. All of them should offer a free trial period to use them, so I encourage you to download one or several and kick the tires. Find one that has the features you need at a price you can afford. Don't underestimate the cost savings in productivity with a good editor.
Now you are ready to script. Well, almost. Open your editor and start writing script comments in plain language that outlines what each part of your script is going to do. Insert some blank lines between comments. Now all you have to do is write the code to meet the requirements and when you are finished, your script is well documented.
I encourage you to insert trace and debug messages as you write your script. If you include cmdletbinding, then you can take advantage of Write-Verbose and Write-Debug:
#requires -version 2.0
[cmdletbinding]
Param([string]$computername=$env:computername)
Write-Verbose "Starting the script"
Write-Debug "Computername = $computername"
Write-Verbose "Testing connectivity to $computername"
#verify computer can be pinged
If (Test-Connection -computername $computername -quiet) {
#my code here
...
Write-Verbose "Ending script"
In this snippet I can "turn on" the Verbose and Debug cmdlets by running my script with the -Verbose and -Debug parameters respectively. You don't have to define the parameters. Using the cmdletbinding attribute automatically enables them.
My final word of advice is not to try and write a monolithic script or complex pipelined expression all at once. Write and test each segment. Verify it works in the console. Then build on it, testing each step of the way. Otherwise, if you wait until your opus is complete and it fails, it will take longer to figure out where the problem lies.
There are many other scripting and PowerShell best practices but this should be enough to get you started. If you are looking for more guidance, find me on Twitter @jeffhicks or on Google+.
About the Author
Jeffery Hicks is an IT veteran with over 25 years of experience, much of it spent as an IT infrastructure consultant specializing in Microsoft server technologies with an emphasis in automation and efficiency. He is a multi-year recipient of the Microsoft MVP Award in Windows PowerShell. He works today as an independent author, trainer and consultant. Jeff has written for numerous online sites and print publications, is a contributing editor at Petri.com, and a frequent speaker at technology conferences and user groups.