new feature: unusable parameters warning

[iricigor]

Problem to be solved

PowerShell (theoretically) supports parameters whose name can consist only from numbers. For example, this is a valid declaration:

function p1([switch]$1) {if ($1) {'Yes'} else {'No'}}

However, it is very hard to call properly this script. This one will not work:

PS /home/iiric> p1
No
PS /home/iiric> p1 -1
No

This is because parser will think -1 is a negative number rather than a parameter name in this instance.

Proper (=hard) way would be to use splatting.

$params = @{ '1' = $true }
PS> p1 @params
Yes

Generally, this is not the only example of such unusable parameters. See response by @vexx32 in PowerShell repo issue.

Summary of the new feature

Create a PSSA rule that warns when such parameters are created, so users are aware ahead of time that they're making parameters that they won't be able to refer to.

[bergmeister]

Thanks for raising this and taking your time
Can you please help me understand why would one want to declare such a parameter in the first place? Can you please explain what led you to this scenario? It's not a readable parameter name anyway.
PowerShell's parser allows it because other characters could follow and you show that with splatting it's even possible to use it. PowerShell's philosophy is often as follows and I'll quote Bruce (one of the original architects): 'We will let you shoot yourself in the foot but we will not hold the gun'
PSSA rules are for scenarios that are common and could help other people not fall into the same trap. I struggle to understand how this scenario could happen to more than 1 or 2 people. Also: Even if one makes this mistake, everyone should and will test or run their function at some point and rectifying the problem should be a simple quick fix.

Code analyzers are there to help but cannot detect every possible scenario and just to compare it to the C# world: One can define a property with a reference to itself in the setter that will cause a Stackoverflow crash, this is something that has maybe happened to every other developer once but there is no rule to warn against it.

Let me know what you think and if you'd even be ready to implement this rule yourself.

[iricigor]

My idea that led me to this problem was to implement equivalent of Linux commands head -1 file and tail -1 file in PowerShell. Those commands list first/last line from a file. Yes PowerShell can do it with Get-Content 'file' | Select-Object -First 1, but I had an idea to do it with Select-First -1. However, I failed on parameters parsing. As PowerShell is approaching Linux, I think more people might hit it.

About implementation, yes, why not, I could try to do it. I presume covering exact cases mentioned here might not be hard. Loop would be very similar to AvoidDefaultValueForMandatoryParameter and checking for parameter name would be even easier.

Do you think its worth having this rule?

[bergmeister]

Ok, interesting. If you're going to open a PR then go for it, there is no heavy lifting or hard work involved, so I am not too worried about performance impact of a rule for a rather rare case. At the end the community should be able to add the rules they want as long as they make sense and they are not controversial/opinionated, so I don't see any problems with adding such a rule as long you lead the effort.
If you have a question or get stuck during development, I'd still be there to help you out in order to make your PR successful :)

[iricigor]

Work started in a fork.

[iricigor]

The PR above is closed due to wrong rebasing. I will open a new one soon.