Although more commonly associated with “waste management”, this can also be applied to your PowerShell code! In the end, you don’t want to continuously write the same code. You want to create functions and optimize the code in those functions to be adaptable…
So what is it you are trying to achieve?
In general we can categorize code written in PowerShell in 2 big factions: Tools and Controllers…
Tools are single issue, problem solving, specialists. For example deploying a Virtual Machine in your environment…
You’d have to:
– Create the Virtual Machine
– Assign it a network
– Assign the resources required
– Create hard drives
– Assign those drives to the Virtual Machine
– Install an Operating System
– Configure the OS with software.
All of this is highly reusable, and each of these steps can be created in separate functions.
Controllers would use the tools you’ve created, calling them in the proper order, and either log to the screen, a log file, or both.
So when we’re creating a possible solution to a business problem (or automating a process), we first need to think of what it is we’re trying to achieve, and what we’re going to write…
Be consistent, be modular!
Try to make your tools as modular as you can! Only accept input through parameters, only provide output through the pipeline.
Try to use the verb-noun cmdlet naming as you see in all of the Microsoft cmdlets. One of the things that makes things so darned easy in using PowerShell is that you can look at the name of a cmdlet, and pretty much understand what it is going to do from looking at the name of the cmdlet.
There exist, in a far off and wonderful land, a list of approved verbs for PowerShell Cmdlets:
That neat thing you wrote? It’s built in already…
Once you get to a point where you’re solving problems which have already been solved in the default set of cmdlets provided by Microsoft you’re pretty much stealing from yourself. Sure, sometimes it’s fun writing a new ping functions, but the reality is that you might have just wasted your own time, as you could have just used Test-connection.
There are the exceptions to this, of course, but as with everything, the exception doesn’t make the rule…
Find a bug, report a bug
There are many a smart people working at Microsoft that create cmdlets. And as with all software that gets developed, bugs will creep their way in to the code. So if a cmdlet doesn’t work as expected, do report it on connect.microsoft.com. Not only are you helping yourself (the bug might actually get fixed!), but you’re helping the community by lending your voice to it.
Sometimes PowerShell native isn’t the best way to go…
There are tools that are vastly superior to the native, built-in cmdlets. In those cases it’s quite alright to call them in your code, but you should account for them! Comment as to why you’re using these tools. Document it somewhere. Create prerequisite checks so your code handles that specific tool not existing.
The amount of times I’ve had to dig my way through code, only to find some obscure tool was being called without mentioning it in the documentation, or providing error handling for it not being in it’s hard coded path (I just started twitching) has made me slightly frustrated!
HBoPS #1: Use a proper editor!
HBoPS #2: Error handling and you!
HBoPS #3: Avoid using Write-Host (and save puppies!)
HBoPS #4: Variables, Parameters, and Battlestar Galactica
HBoPS #5: Reduce, Reuse, Recycle
HBoPS #6: Handling Credentials