As a follow-up to my last post, this week I'll be looking at different options for how to make the PowerShell® code for my Busylight more manageable and easier to reuse. To start with, I'm going to focus on simply setting the Busylight to either be green, red, or blue. We'll initially look at just using a basic script, and then we'll move on to making code more portable via functions.
The simplest way to do this is to just copy all my code (the massive five lines) into a .ps1 file, and change the colour values as needed. So, I could end up with three virtually identical files, (SetBusyLightToGreen.ps1, SetBusyLightToBlue.ps1, and SetBusyLightToRed.ps1), where the only thing changed is something similar to:
Running is easy; it's not any more complicated than calling .\SetBusyLightToGreen.ps1. However, that's not ideal, because any future change would then require me to replicate it across x number of files. For example, if I wanted to add in some error handling, it's now three updates. And if I want to create a file for the colour purple—well, that’s another file to look at.
A better approach is to move all my code into a single file, and break the units of work into smaller code. When the script runs anything not in the script body will run, and code within the functions will only run when the function is called. Creating a function is simple. Just use the FUNCTION keyword, followed by the function name, and the script code itself enclosed within a pair of braces. So, in this example, the first three lines are called as soon as the script is run, and the functions only when explicitly called. Not only can we now call this function within the script, but once we open the console running the script, those functions will exist in-memory, so they can be called whenever we want. We can also make use of tab completion. Each function should ideally do just one thing, and do that one thing well. Also, it should be able to work with objects both as inputs and outputs on the pipeline. These are more advanced topics, and we’ll go into further detail in future posts, but they’re worth bearing in mind even at this early stage.
Before we go further, it’s worth spending a few minutes discussing naming conventions. When it comes to naming PowerShell functions, consider cmdlets, even though technically a cmdlet needs to be something that is compiled. Essentially, each function should follow a verb-noun format, with the verbs in particular needing to conform to approved verbs. This is why things like “set-busylighttogreen” makes it easier for you to understand what your code does, while also acting as a helpful document for the next person who has to read it. You should also get in the habit of always using the full command name in scripts. But if you’re working from the CLI, you can also set aliases for your most common commands. So, instead of doing a “get-childitem,” you can use a ls, dir, or whatever is more intuitive. I tend to use notepad++ quite often, so I have an alias set in my profile. Instead of calling “C:\Program Files\Notepad++\Notepad++.exe,” I can now just call np from the console.
You’re probably asking, “Why bother with all of these extra steps?” Well, the end goal here is to allow us to easily reuse code. While a simple script may do the exact job today, if we have a similar but different requirement farther down the line, a rewrite would be needed. Having our code in functions also gives us the flexibility to determine how we call the code. Not only can we reuse code in other scripts simply by copying and pasting, but we can also place it in our profile script so that it's always available from the console. Ultimately, however, we will see that by placing our functions in modules, we will have the most flexible deployment approach. Wrap-Up In this post we looked at the basics of building a function. In the next, we’ll look at the steps involved in converting these functions into a module. We will continue to build on this in future posts, discuss error-handling and implicit help information, as well as ways to use Pester to build tests around our code.
Exit-PSSession "Blog Session"
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.