Aliases, Types and Type Constraining

Comments None

After a few weeks’ break for Christmas, I’ve returned to blogging and tonight we’re looking at a couple quick rules to help the reuse of our code.

There are more proper and less proper ways to do things in many programming languages. Some have very clear conventions to follow, and some seem to be the Wild West of programming tricks and shortcuts. The former are nice because you can generally tell what something does and whether it will work by looking at it, and the latter are good because you can get results very quickly, and you will feel like you know kung-fu. (Hint: pick legible syntax over kung-fu whenever possible… even when you are not going to re-use your code, you will have an easier time retaining knowledge if you are not using “tricks” to get your task done).

Below I will cover a few good hygiene habits that will help your work stand the test of time, while also exercising and deepening your understanding of the ‘Shell.

One of the easiest shortcuts PowerShell provides are CMDlet aliases. These shortened or alternative names are nice for their brevity and familiarity with other shell environments. Two of the most common aliases are “dir” and “ls.” Both are used in lieu of Get-ChildItem and are likely familiar to DOS and Unix users respectively. Aliases are invaluable in the console window, but always prefer typing out the full command name in saved scripts. Yes, the next admin to come along can simply open up a console and type “Get-Alias sujb” but it is better if you just used “Suspend-Job” in your saved script in the first place so she does not have to. I would especially avoid the aliases “%” (ForEach-Object) and “?” (Where-Object) in saved scripts, as the novice PowerShell user may very easily mistake them for wildcards or some strange operators. Rather than confounding them, we should be enlightening and gently guiding our acolyte coworkers, helping them in their own journeys in the ‘Shell.

We must make a similar consideration when it comes to type declarations. When you create functions for re-use, type constrain and or validate your parameters. That means that your function will demand that the parameters it receives are of the exact type of data that it needs to execute. Sometimes data can be ambiguous, and errors or, worse, undetected strange behavior, can occur. PowerShell data types are declared by the type name in square brackets “[ ]” before the data or variable, e.g., “[string]$x”.

For an example of the importance of type constraints, enter the following lines individually in a console window, followed by enter, and see what is returned.

2 + 2
"2" + "2"
"2" + 2
2 + "2"

Does it make sense what is happening? When you use quotes, PowerShell interprets the character 2 as a string, rather than an integer. When PowerShell adds strings, it appends the second one to the first. When it adds integers, it is doing math. When mix up the line with quotes and no quotes, PS type casts the second piece of data to match the first, so that it can perform the appropriate kind of addition.

PowerShell does not enforce strong typing, but that does not mean you cannot enforce strong typing in your functions. What does it mean to enforce strong typing? It simply means we declare the type of data for our parameters within the function. Let’s make weakly typed function of the mess above.

Function AddMe ($number1,$number2) {
Write-Output ($number1 + $number2)

Now if you iterate over the combinations above as parameters, you get the same results.

AddMe "2" 2
AddMe 2 "2"

Now let’s type constrain the function and try again. As we are clearly looking to do arithmetic, we’ll demand that the parameters are integers. Now, even when they are implicitly specified as strings, the function will cast them as integers and return the correct value.

Function Addme ([int]$number1,[int]$number2) {
Write-Output ($number1 + $number2)
AddMe "2" 2
AddMe 2 "2"
AddMe "2" "2"

See how nice and consistent that is? Learning about the specific data types silently sliding down the pipeline is an important step in our mastery of PowerShell, and requiring data of the appropriate type can harden our scripts against human error.



There are currently no comments on this article.


Enter your comment below. Fields marked * are required. You must preview your comment before submitting it.

← Older Newer →