Thoughts on Powershell Parameter Naming Conventions

If you haven’t seen the Microsoft Virtual Academy series on Active Directory and Powershell yet, you should check it out here. Hosted by Ashley Mcglone and Jason Helmick, it has tons of information on how to get started using Powershell to manage Active Directory and there is some great supplemental material that you can download and work through on your own.

Anyway, I was thinking about one of Jason’s comments in the series regarding Powershell parameter naming conventions. Specifically he says that the -Properties parameter of Get-Aduser should be -Property instead. According to MSDN, Powershell cmdlet parameter names should always be singular unless they only take multiple values as an argument. Since -Properties accepts either a single value or an array of values, it should instead be -Property.

First off, -Property is a valid alias for this parameter so if you type it this way instead it will still work. However tab completion will always fill out the plural version of the parameter. I think that this particular practice in general is flawed and I’ll tell you why – because it doesn’t help anyone.

The practice I prefer is to always use singular names for parameters that can only accept single values, and always use plural names for any parameter that can accept multiple values. The reasoning is simple – you can tell just by looking at the parameter name whether it accepts multiple values or not. You don’t need to run get-help at all in order to see that Get-ADUser -Properties Title,Department will work. Also, I don’t know of many cmdlet parameters that only accept multiple values. I am sure some exist, but it’s far more common to have parameters that will accept an array with only one element.

As always, comments and criticism are welcome.

Challenge Yourself with Powershell Programming Tasks

Scripting Outside the Box

If you are like me, you probably took up Powershell as a way to address a particular business need. For me, that need was managing some aspects of Active Directory and Office 365. This is a great approach to learning the language, but it has its drawbacks as well. If you are only using Powershell to deal with the systems that you normally manage then you can get caught up ‘in the box’ and your learning can stagnate. A challenge I faced early on was how to keep the pace of learning up and continue to challenge myself. What I began to look for were arbitrary challenges that could help me take my Powershell problem solving to the next level. One website I found for this is Rosetta Code.

Rosetta Code is a wiki community that focuses on comparing programming tasks in different languages. You can choose a programming task and then post your solution to the problem in the programming language of your choice. Some of the tasks are relatively complex math puzzles, others are word-based, and some are simply common tasks like reading text from a file or printing to the screen.

A Sample Task

My favorite tasks on Rosetta Code are the number challenges that got me thinking about how to achieve a Powershell solution in a more ‘programmer-y’ way. Here is one of the solutions I found that uses recursion to achieve a goal – The Hailstone Sequence. The task’s description goes like this:

The Hailstone sequence of numbers can be generated from a starting positive integer, n by:

  • If n is 1 then the sequence ends.
  • If n is even then the next n of the sequence = n/2
  • If n is odd then the next n of the sequence = (3 * n) + 1

The (unproven), Collatz Conjecture is that the hailstone sequence for any starting number always terminates.

Task Description:

  1. Create a routine to generate the hailstone sequence for a number.
  2. Use the routine to show that the hailstone sequence for the number 27 has 112 elements starting with 27, 82, 41, 124 and ending with 8, 4, 2, 1
  3. Show the number less than 100,000 which has the longest hailstone sequence together with that sequence’s length.
    (But don’t show the actual sequence!)

To solve the first two steps of the task, I wrote a function called Get-Hailstone:

This fairly concise piece of code uses a switch statement to implement a recursive Hailstone algorithm. Wikipedia defines recursion as “a method where the solution to a problem depends on solutions to smaller instances of the same problem” – in other words, a block of code that uses itself to define itself. You can see this in practice in Get-Hailstone which calls Get-Hailstone inside it’s function body.

The switch statement that makes up Get-Hailstone has four conditions. The first is simply a validation to ensure that the number provided to the function is not negative or zero.

The second condition is known as the base case. In recursive programming, the base case describes a condition where the recursion will terminate. If a base case is not included then the recursion can loop forever – like the infinite mirror trick. For the Hailstone sequence we set the base case to return when $n equals 1.

The third and fourth conditions are ‘recursive cases’ and decide how to modify $n based on the requirements of the Hailstone sequence. I use the modulus operator (%) to determine if $n is even or odd, output $n, and then calculate a new $n to be passed back into the function. If you aren’t familiar with the modulus operator, it simply performs division and returns the remainder instead of the quotient. Thus using 2 as the divisor is an easy way to determine whether a number is even or odd.

Get-Hailstone is quick! On my laptop it can calculate the hailstone sequence for a 50-digit number in less than 200 milliseconds.


Here are some other tasks I have provided solutions to:

100 Doors
Digital Root
Sum Digits of an Integer
I Before E Except After C

So what are you waiting for? Get out there and attach an unsolved task, or let me know how you would solve the problems I posted.

P.S. For fun and extra credit, Google ‘recursion.’ 😉