PSScriptAnalyzer deep dive – Part 1 of 4

Doctor Scripto

Summary: Thomas Rayner, Microsoft Cloud and Datacenter Management MVP, shows the basics about how to use PSScriptAnalyzer.

Hello! I’m Thomas Rayner, a Cloud and Datacenter Management Microsoft MVP, filling in for The Scripting Guy this week. You can find me on Twitter (@MrThomasRayner), or posting on my blog, workingsysadmin.com. This week, I’m presenting a four-part series about how to use PSScriptAnalyzer.

Part 1 – Getting started with PSScriptAnalyzer

Part 2 – Suppressing, including, excluding rules

Part 3 – Wrapping PSScriptAnalyzer with Pester to get formatted results

Part 4 – Writing custom rules

This is Part 1, so I’m going to introduce you to PSScriptAnalyzer and show you how to get started.

PSScriptAnalyzer (or PSSA), is an open-source tool that Microsoft developed. Its source code is hosted on GitHub. The purpose of PSSA is to offer a tool that checks PowerShell code against a set of rules based on best practices. It comes with a bunch of built-in rules and you can add your own.

The default PSSA rules, which cover a wide variety of best practices, are an excellent starting place. Just to mention a few: PSSA will check your script and warn you about using aliases instead of the full name of a command, using Invoke-Expression and other dangerous cmdlets, naming your functions correctly, and a whole lot more.

So, how do you get started? First, you need to install the PSScriptAnalyzer module.

Install-Module -Name PSScriptAnalyzer -Scope CurrentUser

You can verify that the PSSA module was installed by running the following command.

Get-Module -Name PSScriptAnalyzer -ListAvailable

And you’ll get output like this:

Verification that the PSSA module was installed

Now, you just need to import the module so you can use it.

Import-Module -Name PSScriptAnalyzer

Like with any module, you can easily explore all the commands that it brings into your session.

Get-Command -Module PSScriptAnalyzer

There are only two: Get-ScriptAnalyzerRule and Invoke-ScriptAnalyzer. We’re going to look at Get-ScriptAnalyzerRule another time.

Now you are ready to run your first test. It’s as easy as running Invoke-ScriptAnalyzer and specifying a path to a script. In this example, I have a script named “MyScript.ps1” whose contents are as follows.

param (

$Path, $DaysOld )

$someVar = $null

Write-Host "Counting items..."

$itemCount = (gci $Path | ? { $_.LastWriteTime -gt (Get-Date).AddDays(-$DaysOld)}).Count

Write-Host "There are $itemCount items"

The script takes a path to a directory and gets all the items that have been written more than the specified number of days ago. You might be able to tell that there are some problems with this script already, just by looking at it. Let’s see what PSSA says.

I can run Invoke-ScriptAnalyzer on my script…

Invoke-ScriptAnalyzer -Path .\MyScript.ps1

… and see that there are some glaring violation of best practices.

Result of running Invoke-ScriptAnalyzer -Path .\MyScript.ps1

As you can tell, there’s a bunch of problems here. It looks like my script violates the following rules:

  • PSUseDeclaredVarsMoreThanAssignment
  • PSAvoidUsingWriteHost
  • PSAvoidUsingCmdletAliases

PSSA even tells you the line of your script where the violation occurs and provides a more detailed descripton of the rule violation. For example, on line 6, I declared $someVar but never used it in the rest of my script.

Using this feedback, I change my script to make it is faster, more efficient, easier for other people to understand, and generally more conforming to PowerShell coding best practices.

I should mention that sometimes you have a valid reason for breaking a PSSA rule, and they aren’t all perfect. It’s up to you to know your work well enough to interpret the PSSA results and decide whether they are valid. We’re going to talk more about that tomorrow.

Thanks Thomas!  Looking forward to tomorrow’s read!

I invite you to follow the Scripting Guys on Twitter and Facebook. If you have any questions, send email to them at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow.

Until then, always remember that with Great PowerShell comes Great Responsibility.

Sean Kearney Honorary Scripting Guy Cloud and Datacenter Management MVP

0 comments

Discussion is closed.

Feedback usabilla icon