Summary: Microsoft Scripting Guy, Ed Wilson, talks about Windows PowerShell best practices for simple scripts.
Microsoft Scripting Guy, Ed Wilson, is here. “Heyyyyy! Script it, baby!” The words of Scripting Cmdlet Style continue to echo through the house. If you have not seen the latest Windows PowerShell community video by Sean Kearney, you should definitely check it out. It is really well done, and so far, it has received four thumbs up on You Tube.
When I am working with Windows PowerShell, and the command begins to wrap to the second line, I start thinking about migrating to the Windows PowerShell ISE. If the line goes beyond two lines, I definitely move to the ISE. The reason is because command-line editing is rudimentary in the Windows PowerShell console, and also because the commands begin to be difficult to read. Also, as the length of command increases, my chance of executing the command correctly the first time decreases. If I pollute my Windows PowerShell console history with a bunch of commands that do not work properly, the whole thing becomes an exercise in futility.
Therefore, I view a simple script as only a little different than the Windows PowerShell console itself. It serves the same essential purpose: to allow me to quickly and efficiently execute simple Windows PowerShell commands. Therefore, my best practices for simple scripting are much the same as they are for the Windows PowerShell console:
- A simple script is 15 lines or less.
- A simple script is straight line execution (no functions).
- I do not feel compelled to use full cmdlet names, aliases are permitted.
- I do not feel I need to avoid positional parameters.
- I do not set strict mode (Set-Strictmode).
- I do not generally initialize all variables prior to use.
- I do not generally add comment-based Help.
- I add single line comments to clarify usage.
- I might add a single line comment that illustrates a sample command.
- I generally save the simple script with a reasonable name in my script folder.
- I do not bother with version, date, or other “header” types of information.
- If I had to look something up on MSDN, I will generally paste the URL in a comment.
- Often I will use the ISE to write a quick one-off script, and not save the script. In these cases, it is exactly like using the Windows PowerShell console, except that I have a bit better syntax highlighting.
- I use the Script Browser to find sample script, but do not use the Script Analyzer.
- I avoid end-of-line comments. Instead, I place comments on the line above the command to be commented, and I do so at the beginning of each line.
- I line up related objects and pieces of syntax; therefore, I pay attention to good formatting.
- I generally break each line of script at the pipeline character. Most of the time, I do not have more than one pipeline character on a single line.
- I leave pipeline characters to the right of the script.
- I will generally pipe to a Foreach-Object, instead of storing in a variable and using the ForEach statement to walk the collection.
- I always prefer a Windows PowerShell cmdlet to a COM object or to creating a .NET Framework class and calling methods and properties from that.
- I store credentials to a variable, and I use it during my Windows PowerShell sessions in the ISE.
- I often close the Windows PowerShell ISE to ensure I am not inadvertently taking advantage of an object created during a different scripting session. This is the best way to clear variables; remove objects; and release PS Drives, COM objects, and other scripting paraphernalia.
That is an introduction to Windows PowerShell best practices related to quick scripts. Best Practices Week will continue tomorrow when I will talk about functions.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at firstname.lastname@example.org, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy