Warn on using incomplete parameter name

[rkeithhill]

You open your script up to a future breaking change if you use a command parameter and not specifying the full parameter name. For instance, say I use Get-Foo -R in Foo module v1 where Get-Foo has only one switch parameter -Recurse. This works until Foo v2 comes out and the author has add a new parameter to Get-Foo called -Rollback. Now all of a sudden that script with Get-Foo -R will start failing due to an ambiguous parameter name.

[KirkMunro]

A precaution comes to mind here. I have seen cmdlets that have extended a
parameter name from one release to the next. For example, Get-Foo
-Computer in one release, and then Get-Foo -ComputerName in another release
once they realize they should be consistent with the -ComputerName
parameter. With this proposed rule, scripts would all of a sudden warn
when a module was updated, when they didn't previously warn. It's a bit of
an edge case, but I wanted to add it here just as food for thought while
considering this rule since it has happened before.

*Kirk Munro *
Poshoholic, Microsoft MVP
Blog http://poshoholic.com/ | Twitter http://twitter.com/poshoholic |
LinkedIn http://ca.linkedin.com/in/kirkmunro | GitHub
http://github.com/KirkMunro | Facebook
http://www.facebook.com/#%21/kirk.munro

Need a PowerShell SME for a project at work? Contact me
http://poshoholic.com/contact-me/!

On Tue, Aug 18, 2015 at 4:05 PM, Keith Hill [email protected]
wrote:

You open your script up to a future breaking change if you use a command
parameter and not specifying the full parameter name. For instance, say I
use Get-Foo -R in Foo module v1 where Get-Foo has only one switch parameter
-Recurse. This works until Foo v2 comes out and the author has add a new
parameter to Get-Foo called -Rollback. Now all of a sudden that script with
Get-Foo -R will start failing due to an ambiguous parameter name.

—
Reply to this email directly or view it on GitHub
#294.