What’s in a name? Using prefixes in PowerShell.

PowerShell Team

We’ve talked about this in the past but it’s time for a reminder.  PowerShell uses prefixes in front of nouns to avoid name collisions.  Imagine how many collisions there would be if people used the noun “USER” directly.  Instead, we have cmdlets *-ADUser, *-VPNUser, and *-RDUser.  The use of the prefix avoids name collisions.  When there is a name collision, the customer must specify the full name of the cmdlet.  Did you know that the full name of Get-ADUser was actually ActiveDirectory\Get-ADUser?  How would you feel if you had to type that every time you wanted to invoke that command?

The use of prefixes also makes it easy to find related components.  Look how easy it is to find all the PowerShell settings by searching for variables with the “PS” prefix:

Image 3730 PSNameLarger

It is important to use prefixes.  There are two other rules you need to know:

  1. The prefix for PowerShell is “PS”.  If you use the “PS” prefix, we can and will collide with you.
  2. There are two scenarios where PowerShell will use generic nouns:  When we cover a system resource (e.g. *-Process) or where we provide a pluggable framework for an area (e.g. Drives, Jobs, Events, etc.).

Moving forward, we anticipate continuing to create modules, environment variables, file extensions, and other content types using the “PS” prefix and creating additional pluggable frameworks where we will use generic nouns. If you don’t use a prefix or use the PS prefix, you are setting yourself up for a collision.

We don’t want to create naming conflicts – that’s why we have insisted on the use of prefixes from the very early days on PowerShell and why we started using the “PS” prefix.

To Sum Up

Use noun prefixes and avoid the “PS” prefix to deliver a great customer experience and minimize/avoid name collisions.

Thanks,

Jeffrey Snover and John Slack

0 comments

Discussion is closed.

Feedback usabilla icon