It’s really interesting to see how PowerShell scripting has evolved over the years. Early on, PowerShell scripts tended to be simplistic in nature, and focused on performing a single repeatable task. As time went on though, PowerShell scripts have often become increasingly complex. In fact, I have seen full-blown GUI applications written in PowerShell.
Part of the reason why it is becoming far more common to see elaborate PowerShell scripts is because PowerShell itself has become more feature rich and capable with each released version. Of course you could probably also attribute part of it to the fact that PowerShell has been around for so long and a lot of people have gotten comfortable with writing PowerShell code. Regardless, one of the interesting trends that I have seen regarding PowerShell scripting is the adoption of practices that have been traditionally reserved for “real” development environments.
One such practice is the adoption of dry PowerShell scripts. Dry is an acronym that stands for Don’t Repeat Yourself. It’s based on the idea that scripts should never include redundant code. It’s better to simply code everything once and then reuse that code as often as is needed.
The flip side to that is something called wet scripting. As you probably already guessed, wet scripting is essentially just a script containing repetitious code. Wet scripts are generally looked down upon, and the term wet has been used as an acronym for all kinds of things such as, Waste Everyone’s Time or We Enjoy Typing.
So when it comes to PowerShell, is it better to create wet or dry scripts?
Based on the things that I have said so far in this article, the choice seems obvious. Even so, I’m a firm believer in the idea that everything has its place. While there are clear advantages to writing dry scripts, I think that a case can also be made for writing what scripts – at least in special circumstances.
The fact that some people claim that wet stands for We Enjoy Typing would seem to imply that one of the big advantages to creating a dry script is that the script is shorter in length. However, that isn’t necessarily true. Imagine for a moment that you wanted to create a PowerShell script that displayed the words Hello World on the screen and then repeat the phrase on the next line (displaying the text twice). Here’s what a wet version of such a script might look like:
Write-Host “Hello World”
Write-Host “Hello World”
Now, here is an example of a dry version of the same script
Function Hello-World
{
Write-Host “Hello World”
}
Hello-World
Hello-World
The wet version of the script consisted of two lines of code, while the dry version contained six lines of code. The dry script’s function calls alone were as long as the entire wet script. The point is that dry scripts aren’t always shorter. In this example, the dry script was three times longer than the wet script.
Similarly, dry scripts aren’t always easier to debug (although they can be). After all, would you rather debug two lines of code or six? My point is that when it comes to creating really short, simple scripts, dry scripting is often overkill. Incidentally, there are dry scripts that are shorter than wet scripts. One type of script isn’t necessarily going to always be shorter than the other. It just depends on how the script is written and what it is designed to do.
So why might a dry script be superior to a wet script? The real advantage to using a dry script is that it gives you consistency. When you write a function, that function is going to behave in exactly the same way every time that is called. If on the other hand, you were to just type a set of commands every time they were needed rather than turning those commands into a function, then there could be minor variations from one instance of the command block to the next. When you write a block of code and turn it into a function however, you only have to debug that code once. That’s the real advantage to dry scripting.
In my opinion, dry scripting is usually the best approach for all but the simplest scripts. Even so, I have seen two situations in which dry scripting did not work out so well.
The first of these was a situation in which someone took the concept of dry scripting to the extreme. This person’s script functionalized everything, and I do mean everything. The script was a convoluted mess of nested functions and the entire script body was just a long chain of function calls. Because of the way that the script was written (with all of the constant bouncing around between functions) debugging the script proved to be a monumental effort. The big lesson that the person learned through their debugging efforts was that if you are going to write a script like that then you should debug each function as you create it. Otherwise, it just becomes too difficult to find the source of a problem.
The second example of a PowerShell script where dry scripting didn’t work out so well was one in which all of the functions were incorporated into a module rather than being included in the script body. Creating custom modules is a relatively common practice and there is nothing wrong with building modules. The reason why it was problematic in this case was because the script was given to several other people, none of whom realized that there were external dependencies.
So what is best for PowerShell, wet scripts or dry scripts? As a general rule, I tend to think that dry scripts are the best approach for the vast majority of situations. Even so, there is such a thing as too much of a good thing and so its important to make sure that dry scripting techniques are not taken to the extreme to the point that any benefits are completely negated.
