Use PowerShell

PowerShell V3 – Default Parameter Values

2012-01-06T16:45:41Z

PowerShell Version 3 introduces the concept of Default Parameter Values.

This allows you to specify a value for one or more parameters for one or more commands.

To implement this, you need to populate a new hashtable – $PSDefaultParameterValues

That Description is Not Helpful

Let’s look at some examples –

First off, we can specify the value for a parameter for a specific command. The pattern used for the hashtable entries is “NameOfCommand:NameOfParameter” = “ValueOfParameter”.

(I’m stealing some of these examples from the samples provided in CTP1.)


$PSDefaultParameterValues = @{"Get-Process:Name"="powershell"}

Get-Process

Get-Process e*

With that set, every time we run Get-Process and do not specify the Name parameter, the PowerShell runtime will stick “powershell” in for that value. A specified parameter will always override a default value.

Let’s go the other way and, instead of specifying one command, set a parameter value on all commands (that have that parameter.


$cred = Get-Credential mydomain\mydomainadminaccount

$PSDefaultParameterValues = @{"*:Credential" = $cred}

This would provide your $cred to any Credential parameter.

We can also use wildcards to match multiple commands.

$PSDefaultParameterValues = @{"*-AD*:Server" = 'MyDomainController'}

This would provide a default value to the Server parameter for any command whose noun started with AD (like everything in the ActiveDirectory module.

Since this is a hashtable, it can hold many different mappings –


$PSDefaultParameterValues = @{

  "*:Credential" = $cred

  "Get-Process:Name"="powershell"

  "*-AD*:Server" = 'MyDomainController'

}

To turn off DefaultParameterValues (without removing everything you have set up), you can set a key “Disabled” equal to $true.

$PSDefaultParameterValues = @{"Disabled" = $true}

This concludes our brief look at DefaultParameterValues for today.

Go grab Version 3 CTP2 and give it a whirl…

When Import-Module Does Not

2012-01-06T16:46:58Z

A question came up about the behavior of Import-Module (in the context of this interesting discussion of whether module authors should provide aliases), especially with Version 3 and the auto-loading of modules (what’s that?).

So What’s the Question?

Does the auto-loading of modules in PowerShell Version 3 use Import-Module behind the scenes? If it does, can we use default parameter sets to control what types of things are imported?

What Actually Happens?

So, it turns out that Import-Module does get called behind the scenes and a default parameter set (new feature) can be used to customize the import of new modules.

$PSDefaultParameterValues = @{
	"Import-Module:Alias"=@()
	"Import-Module:Function"='*'
	"Import-Module:Cmdlet"='*'
	"Import-Module:Variable"='*'
}
Get-Module
Get-BitsTransfer
Get-Module

This example (when used in PowerShell V3) will (from a base PowerShell session) show you what modules are loaded, attempt to run the Get-BitsTransfer command, and then show you what modules are now loaded (should include the BitsTransfer module now). Since we’ve provided an empty array to the Alias parameter for Import-Module, any module that is imported will import any aliases.

Seems Like It Works… Where’s the Problem?

The problem comes in when you specify that only one of the four parameters (Alias, Function, Cmdlet, and Variable).

You might expect that when you specify one parameter (example Alias), that the other portions of the import (Function, Cmdlet, and Variable) would behave just like if you did not specify any of them.

Example -

Open a new PowerShell session (V2 or V3) -


Import-Module BitsTransfer
Get-Command -Module BitsTransfer

Get-Module

This will import BitsTransfer module and all attendant commands and functions. Note the ExportedCommands in the Get-Module output.

Open a new PowerShell session and try -


Import-Module BitsTransfer -Alias @()
Get-Command -Module BitsTransfer

Get-Module

This should import the BitsTransfer without any aliases (yes, I know BitsTransfer doesn’t have any aliases, but I wanted a module that most any Windows 7 or Server 2008 R2 machine would have – feel free to test with whatever module you desire).

This did import the BitsTransfer, but no commands or variables were imported. It only attempted to import aliases, and since we specified that aliases were to be an empty array, nothing was imported.

This is counter-intuitive and is not the experience we should have. Specifying one parameter should not change the default value of other parameters (from all to none in this case).

What Can I Do About It?

First of all, open PowerShell and try it! If you have one of the CTPs of Version 3, try it there. Also try it in V2 using Import-Module directly.

Then go to Microsoft Connect and vote up https://connect.microsoft.com/PowerShell/feedback/details/716857/module-partially-loads-with-import-module.

PowerShell V3 – Auto-loading of Modules

2012-01-06T15:32:38Z

PowerShell V3 includes a new “feature” – Auto-loading of modules.

What Does It Do?

Module discovery has been updated to make the exported commands for modules that are not loaded visible in a PowerShell session.

In Version 2, if you run Get-Module on a module that is not loaded but in your PSModulePath, you’ll get some metadata about the module, but nothing about the ExportedFunctions, ExportedCmdlets, ExportedAliases, or ExportedVariables.

Version 3 changes this, allowing Get-Module to retrieve information on all the exported features of the module.

This enables tab completion to complete the names of commands from modules that are not loaded. It also provides information to the PowerShell runtime on where to get the command information from, if the module is not loaded.

So, in Version 3, if you run a command from a module that is not loaded, the runtime will search your PSModulePath for the first command that it can find that matches that name and load the module that command is in for you.

I’m Not Sold

I really don’t care for this feature. I like to be in control of what module I import. The order in which modules are automatically imported depends on your PSModulePath. You don’t get to pick what the order is… User specific PSModulePath entries are first, then machine specific PSModulePath entries. This can cause a host of unexpected problems when there are command name collisions.

For example, the new Hyper-V cmdlets for Windows 8 cannot manage down-level Hyper-V machines, so you might need James O’Neil’s Hyper-V module from Codeplex. Both modules have Get-VM. Since James’ module will be in my user PSModulePath (most likely), unless I specifically load the Windows 8 Hyper-V module, running Get-VM will always load James’ module.

Starting 2012 with a Bang

2012-01-03T15:30:00Z

I’m so excited for 2012, personally and professionally. I started the year with a great honor, I was awarded a Microsoft MVP award for PowerShell.

Just a bit of background…

I started in IT in 2006 as the IT guy for a municipal police department. It was the first such full time position the department had. I immediately became responsible for a public safety network that needed to be operational 24/7. This required me to deal with a lot of intermittent issues or requests and I quickly saw that I needed some tools to get my job done well.

I looked around and found out that the *NIX guys had it pretty well covered with shell scripting, Perl, Python, TCL, sed, awk, etc.. I went looking for the Microsoft equivalent. I found Python and started doing some scripting with that. I loved the syntax and structure, as well as the availability of an interactive interpreter. The biggest pain was in dealing with the COM layer interactions. I explored C# and began to dabble with that as well.

And then I found PowerShell. I’ve been a PowerShell fanatic since the day I discovered it. It was a shell language. It had a scripting capability. I could extend it with .NET and C#. It worked with WMI and COM in a much more interactive manner and I didn’t have to go through some of the hoops that I had to with Python. It was also a Microsoft product (and eventually was available through Windows Update or with newer OSes in the box), which made it easier to deploy (policy-wise and distribution-wise).

Since that point in early 2006, I have been pushing PowerShell to help in all of the varied environments I’ve found myself in. I’ve become a speaker and a trainer and love sharing the capabilities of PowerShell and seeing others find value and make their work easier (or even possible).

This wouldn’t have been possible without…

I never would have been awarded this without the ceaseless lobbying of Doug Finke and the great interactions I’ve had with various members of the PowerShell team. I know a number of other PowerShell MVPs also were vocal in nominating me (forgive me if I forgot anyone), including Shay Levy, Marco Shaw, Aleksandar Nikolic, and Ravikanth Chaganti. I also had some great support from some of the Clustering MVPs (like Mike Steineke) and team (thanks Rob). Last, but not least, I’ve had great support from my local DPE team. Our local Developer Evangelist, Clark Sell, has never stopped encouraging me in spreading my thoughts on PowerShell and the development of a unified management API to .NET developer groups in our region (and further via his podcast). Our local IT Pro Evangelist, Brian Lewis, has been a stalwart supporter of both user groups we have going in the Milwaukee area, the Greater Milwaukee Script Club and the Greater Milwaukee IT Pro User Community.

Finally,

I want to thank you, the readers of my blog, the attendees of my script club or IT Pro user group, and any of the various attendees of talks I have given. Thank you for allowing me to share a bit of my experience and thoughts with you and I can’t wait to see where this year goes (PowerShell V3 is on the horizon!!!).

Checking Your Pipes For Leaks

2011-09-14T13:00:00Z

(NOTE: I started this post a few weeks ago)

This morning I woke up with my kitchen floor covered in water. As I was cleaning it up, I couldn’t help drawing some parallels between fixing a leaky pipe and a "leaky" (non-performing) script.

My repair process this morning took the following steps:

Contain the leak
Locate the source of the leak
Stop the leak
Check for related damage
Mitigate the related damage
Patch the leak
Confirm the leak is fixed
Monitor the leak site

Since most of you won’t really care about the plumbing in my kitchen, let’s run through how dealing with this problem applies to troubleshooting a misbehaving script (or function).

Containing the Leak

The first step I needed to take was to contain the leak.. in PowerShell, that means I need to pull that script or function from general use, as well as terminating any running instances.

This can be tougher than you think, especially if you are using remote jobs or are performing a sequential series of actions that cannot be rolled back (especially if you don’t have good logging in place!).

Locating the Source

After I’ve got the leak contained, I had to find where the leak was coming from. For my misbehaving script, I either need to find what has failed. Normally, the errors that I’m getting will help point me towards the source of the problem.

However, if I’m not getting errors, I need to step through the script (or function) and can use Set-PSBreakpoint to create an entry point in my script where I want to start walking through.

If my script (or function) is an advanced function, I could use -Debug and have it break on any Write-Debug statements that I’ve used throughout my script. This is a GREAT reason to have a periodic Write-Debug statement before any significant blocks of logic in your script.

Stopping the Leak

Once I’ve found the source of the leak, I can begin to stop the leak. In my kitchen leak, I had to turn off the water.

In the case of my script, I have to find any scheduled tasks using it and stop them or advise other people who might be using the script to stop using it until I can publish a new script.

Checking for Damage

Once I had my leak stopped, I started to check for residual damage that I might have to control. Water had leaked onto where the power cord for my water heater plugged into an extension cord, This caused the GFI outlet to trip.

Collateral damage from a misbehaving script or function can be disastrous. Very often, scripts are run under administrative credentials and can have unexpected side effects. When locating the source of the leak, I’ll check to see what other systems or areas that the script is touching and examine them for potentially improper changes or updates. Finally, I need to document any “damage” or errors that the script created.

Mitigating the Damage

Once I found that the GFI was tripped, I unplugged everything on that chain. I let everything dry out and replaced the extension cord.

For a misbehaving script, this is going to vary based on what the script was actually doing, but this can be one of the most important steps. I have to record all the actions I take to mitigate the “damage” found in the previous step. Even if I decide not to do anything about the damage I found in the previous step, that is still an action and should be documented.

Patching the Leak

Patching the leak is pretty straightforward. Going to the source of the leak, I removed the faulty tap and patched the pipe.

In my script, that means going to the source of the faulty logic or source of the errors and either fixing the logic and/or adding error handling to deal with the source of the errors. I’ll also add additional Write-Verbose or Write-Debug statements to make tracing problems and verifying functionality easier. For scripts that will

Confirming the Leak is Fixed

After I patched the leak, I turned the water back on and watched it for a short while to make sure that there was no seepage from the patch. I tested down-level plumbing to make sure that the pressure was appropriate as well.

After I’ve added my error handling and/or fixed the logic, I’ll run the script again, perhaps with –Verbose or –Debug. If I’m really motivated, I’ll make sure there is the CmdletBinding attribute and add –WhatIf support.

Monitoring the Leak

After I was able to confirm that the leak was fixed, I stayed home and periodically checked the line to watch for any seepage or residual problems. Over the next few days, I continued to monitor the site of the patch for any issues, though not as frequently.

After I’ve fixed my script, I’ll continue to watch was it gets used, perhaps logging all the output, until I’ve regained confidence in the project.

Resources for the WI .NET User Group

2011-09-14T03:51:35Z

I’ll get the slides posted sometime (in the middle of migrating my machine to the developer preview of Win 8), but the links I mentioned are:

—Project Home – http://www.show-ui.com

—Codeplex Site – http://showui.codeplex.com

—Doug Finke’s Blog – http://dougfinke.com/blog

—Joel “Jaykul ” Bennet’s Blog – http://huddledmasses.org

—James Brundage’s Blog – http://blog.start-automating.com/

Where I’ll be this Fall

2011-09-08T15:32:59Z

I wish I could have make it out to Build or the PowerShell Deep Dive, but I’ll settle for these:

September 13th – Wisconsin .NET User Group – Talking about Scriptable UI with PowerShell and ShowUI
September 29th – Greater Milwaukee IT Pro User Group – Talking about the PsTools in the Sysinternals Suite
October 1st – SQL Saturday #98 (Iowa City, IA) – Talking about Scriptable UI with PowerShell and ShowUI
November 1st – LaCrosse IT Pro User Group – Going over an Introduction to PowerShell

Waiter, There’s a Bug in My Get-Help!

2011-08-15T13:00:00Z

My friend Robert Robelo was kind enough to point out a problem with the proxies created by the CommandAssist module.

In trying to research the problem, I found that PowerShell crashed ( yes, crashed.. not throwing an error, but CRASHED) when Get-Help could not resolve the command it needed to provide help for.

Setting the Stage

Reproducing the Problem

Create a module that exports a function

$Path = 'c:\users\smurawski\documents\windowspowershell\TestModule.psm1'
$null = new-item $Path -ItemType File -Force -Value @'
function Test-One {
	[CmdletBinding()]
	param($x)
	$x
}

Export-ModuleMember -Function Test-One
'@

Import the module

Import-Module TestModule

Create the proxy module

Get-Module TestModule |
	New-AssistedModule -ModulePath c:\users\smurawski\documents\windowspowershell\TestAssisted

Import the proxy module

Import-Module TestAssisted

Try to Get-Help for Test-One (shell will crash here)

Get-Help test-one

What’s Happening?

In the proxy command that is generated, there is a help item (ForwardHelpTargetName) that is created to point the help file back to the original command. Since you could possibly have multiple commands, aliases, and functions with the same name, there is a second help entry (ForwardHelpCategory) that allows you to specify what type of command you are forwarding to.

NOTE: The following is my opinion of what is happening based on my testing. I haven’t attached a debugger and watched to verify, but I have tested enough to confirm a workaround. This occurs in both the ISE and PowerShell.exe. I have not tested in other scripting environments.

In this case, both the original command and the proxy are functions, so Get-Help goes into a loop until it hits a recursion max and crashes PowerShell.

Get the Duct Tape

Finding a Workaround

So, how can we get around this? CommandAssist relies on pointing back to the source command for the help files.

Fully qualifying the command in the proxy will solve the problem. I’ve updated the proxy command generation to qualify the command in the ForwardHelpTargetName with the module prefixed name of the source command.

The Downside

If you’ve been playing with CommandAssist, you will want to regenerate your proxies.

Let’s Get This Fixed

Vote it up on Connect!

I don’t know about you, but I would like to see this type of error not crash PowerShell. I’ve filed a Connect bug and would appreciate if you would head over and vote it up! The team really does respond to community feedback and Connect is a great way to show that this is important to you!

Using -Assist in an Assisted Module – CommandAssist

2011-08-13T15:50:34Z

This is the the meat of CommandAssist module, providing a contextual assistant to supplying the right parameters to a command.

Getting to the Meat of It

In the last post, we created a proxy module for ActiveDirectory module, so what does that really get for us?

Starting off in a new shell, I’ve imported the AssistedAD module and I’m going to try out the -Assist parameter for Get-ADUser

Import-Module ADAssist
Get-ADUser -Assist

Initially, I was prompted for a Filter parameter, as that parameter is marked mandatory in the default parameter set. I supplied a "*" and moved on. You’ll notice that I did not have to load the ActiveDirectory module, the CommandAssist module or the ShowUI module, as the proxy module handles all that in the background for you.

What I then got was:

You’ll notice that there are three tabs, Filter, LdapFilter, and Identity. Each tab represents a parameter set and shows the associated parameters for that set.

You will only be able to pass parameters for one parameter set, which can alleviate the common error of

Parameter set cannot be resolved using the specified named parameters

This is a key benefit of CommandAssist versus other tab completion options.

As you add parameters, the command line at the top will change to reflect your changes to the parameters.

Parameters that take a specified enumeration (like AuthType in this case) will have a dropdown box with the available options.

If I change parameter sets, the command line changes to reflect my new parameter selections.

However, your previous selections on an alternate tab have not changed, so you can return to that tab and continue editing if you determine that is the appropriate parameter set to use.

What other information would you like to see here?

Please post a comment on the blog or a message on Twitter if any additional information or features you think might be useful for this! I’d love to hear how you think this might provide value in your usage or your environment.

Creating an Assisted Module with CommandAssist

2011-08-13T15:15:50Z

The CommandAssist module allows you to easily create proxies functions for every command in a module (or snapin).

There is a handy command to generate these proxy modules included with the CommandAssist module.

Building an Assisted Module

The easiest way to explain what happens is to walk through the usage of New-AssistedModule. To that end, we’ll create a proxy of a module that I’ve been use regularly – the ActiveDirectory module.

NOTE: You will need to have ShowUI available in your module path (you can check with Get-Module ShowUI). You do not need to have it loaded into your session, CommandAssist will take care of that.

First we’ll load the CommandAssist module:

Import-Module CommandAssist

Second we will load the module we want to create a proxy for:

Import-Module ActiveDirectory

NOTE: This only has to be done the first time to create the proxy. Afterward, the proxy module will load the real module in the background.

Third we will use New-AssistedModule to create our proxy module.

$NewModulePath = c:\users\smurawski\Documents\WindowsPowerShell\Modules\AssistedAD
Get-Module ActiveDirectory |
	New-AssistedModule -ModulePath $NewModulePath

As noted in the screenshots, the module created has proxies for each command that add the -assist parameter. There also is a module file that will load all of the proxies, as well as the source module (in this example, AssistedAD.psm1).

The next post will review how the -Assist parameter works.

NOTE: The proxy module will load the real module in the background (so if you distribute it, the end user will need the source module or snapin as well).

Using CommandAssist – Assisted Where-Object

2011-08-08T15:00:00Z

To use CommandAssist, the first step you will need to take is to have ShowUI (at least 1.1) installed and run PowerShell in STA mode.

Then, you can import CommandAssist. After importing CommandAssist, you can take advantage of the scriptblock builder built in to Where-Object

Get-ChildItem | Where-Object -assist

When you hit enter, you will see a screen like the below.

At the top of the screen is a count of the number of objects coming into Where-Object. Underneath that is the textbox for the filter scriptblock. After you start adding information to the scriptblock, it will turn green for valid scriptblocks and red for invalid scriptblocks. Underneath that is a count of how many objects will pass through the pipeline after applying the filter.

Two list boxes towards the bottom contain a list of properties available from the incoming objects, as well as the various comparison operators in PowerShell. You can drag and drop those items into the scriptblock builder.

Once you are happy with the resulting scriptblock, you can hit OK and the selected filter will be applied to the objects in the pipeline and pass the remaining objects to the next step in the pipeline.

Announcing CommandAssist

2011-08-08T12:58:15Z

CommandAssist is a new module designed to provide some graphical help for people who are new to PowerShell or just not as comfortable on the command line. CommandAssist relies on ShowUI, so go get it now!

What’s There Now

The first three functions in this module are:

Show-ParameterAssist
New-AssistedModule
Where-Object (with an updated –Assist parameter)

Show-ParameterAssist is the workhorse behind the coolest feature in this module. Parameter assist takes a command (either a CommandInfo from Get-Command, or a command name and what type of command) and optionally a hashtable of parameters and values. It provides a UI with all the parameters (grouped in tabs by parameter set). The UI has parameter help, bolded Mandatory parameters, and let’s you pick enumerations from a drop down menu.

Show-ParameterAssist can be embedded in any function (in the begin block is most effective) before any logic executes. You can assign the output to $PSBoundParameters and also use it to populate the variables for those parameters. I’ll publish some examples soon.

New-AssistedModule takes a module and creates a new module with proxies for each command. In these proxies, Show-ParameterAssist is exposed via an –Assist parameter.

The final command (so far) is the most raw. The module exposes a proxy for Where-Object, with an –Assist parameter that provides a scriptblock builder for the filter. The scriptblock builder has a list of all the properties exposed by incoming objects, as well as a list of all the comparison operators. You can drag properties and operators onto the textbox to build a scriptblock. When you have a valid scriptblock, the background turns green. When it is invalid, the background is red. Also kind of helpful is a counter showing the number of objects being evaluated. When there is a valid scriptblock, there is also a counter saying how many objects will be output.

On the Horizon

For Show-ParameterAssist:

More information about the parameters (can it take pipeline input, etc..)
If a parameter takes a value by property name, include scriptblock evaluation like in Where-Object
Other requests

For Where-Object

Offer better information about the incoming properties.
Improve the drag and drop experience (and parens, and other commonly used cmdlets and expressions)
Improve the help
Other requests

For the module in general:

More built in assisted commands (like select-object)
‘Improve the help
Other requests

If you think this module has some value or have a feature you would like to see, please leave a comment or ping me on twitter, or stop by the PowerScripting Podcast this evening and ask in the chat room. Grab the scripts, look through them and let me know what you think!

Gotta Love Dilbert

2011-08-03T18:37:40Z

I’m on TechNet Radio!

2011-07-01T16:29:55Z

A little while back, I had an opportunity to talk with John Weston on TechNet Radio’s Community Corner.

We talked a bit about PowerShell and the community around it, as well as my local Script Club.

Thanks to John and Chris for taking the time to talk with me, and don’t forget to check out the other great segments in the Community Corner and see what is happening in other user groups!

Back to Basics – Variable Names

2011-05-18T14:10:06Z

$x and $z and $foo just aren’t going to cut it in your production scripts.

Andy Schneider tweeted during the Scripting Games that there was no penalty for providing a descriptive variable name. He was right and not quite right enough. Twitter does not provide you the opportunity to share more than a sound bite in one tweet, so he really could not have commented much further there, but he did in a post that expanded on what judges were looking for in style for the Scripting Games.

The content of that post is not limited to the Scripting Games, but should be applied to our scripting experience.

Down to Business

We’re going to focus on one particular section of that blog post.

Use variables that make it easy to understand what you are doing in your script. Comments in code are great, but your code should be readable and understood without them. In general, I would choose good variable names and clear processes over heavily commented code.

Looking for Trouble

If you find yourself working on a script or function and begin to think, "I need a comment here to make sure it is clear what I’m doing," then you are already headed for trouble. (Function, cmdlet, and script names are another portion for another day.)

Descriptive variable names can serve as inline documentation on what that variable represents. A descriptive variable makes it much easier to follow that variable through the script.

Remember that you might not be (and will likely not be) the last person to look at that script and need to figure out what is going on internally.

If by chance you are the last person to look at that script, do you think you are going to be able to have the same contextual understanding one month after you wrote the script? Two months? Six months or more? I know that when I review scripts I wrote years ago, before I followed my own advice better, it can take me a while to figure out what is really going on, even in some medium complexity scripts (where I should really just be able to scan and understand).

Why Aren’t Comments Good Enough

Comments are not the workaround for poor variable naming. Scripts are rarely static entities. As requirements change, scripts are updated, sections of functionality are changed and the objects that are operated on can change as well. Comments are often the last thing to be reviewed (if at all), so the likelihood of ending up with stale and misleading comments goes up with each revision.

Another reason that comments aren’t good enough is that they clutter up the script file. Comment-based help is one thing (and that is localized to one place in the file, not spread across the script. When I’m reading a script and there are lines upon lines of comments, it really gets in the way of understanding what is happening in the script. PowerShell is rather unique in the case, since the syntax actually lends itself well to self-documenting code (with how the command naming works).

Naming Guidelines

These are some of the guidelines I try to follow when naming variables.

Do Not:

Pluralize variable names that are not arrays.
Pluralize variable names that are used as parameters.
Reuse counter variable names. If you have a variable acting as a counter for a loop, so not reuse that variable name (you may have unexpected results if you don’t clean up after the previous loop).
Use generic names like $Results or $Output.
Use custom abbreviations. Example: $CN should not be used for $ComputerName.

Do:

Describe the instance (or instances) of object(s) contained in the variable
Reference similar values consistently. If you have a variable $ComputerName which has an array of computer names, don’t also have a variable $server or $servers that refer to the same data.
Use singular nouns. This maintains consistency with parameter names which by best practice are singular. The PowerShell convention is that variables with a singular noun can contain one or more objects.
Consider that you might be reading this script at 3 in the morning during an active outage. Pick names that will help you know what is going on and get your work done, so you can go home.
(optional) Use company and industry accepted abbreviations or acronyms. (For example $VM conveys the same information $VirtualMachine to systems administrators.

I’d like to hear what guidelines you’ve followed or what you thing of mine, so post a comment!