PowerShell
Rule request: `AvoidNewObjectCmdlet`
The New-Object cmdlet is basically* legacy.
Since PowerShell V3.0 (12 years ago), PowerShell supports type accelerators which perform much better, see: PowerShell scripting performance considerations / object creation.
*) Exceptions left there (e.g. with the use of the [-ComObject] <String> parameter)
Therefore I think that it makes sense to have a AvoidNewObjectCmdlet rule.
related: Avoid New-Object Hashtable #60
You might also consider to link this type of rules to the #Requires -Version x.x statement.
(In case it doesn't exist in the concerned script: simply suppress the warning.)
Agree with it, feel free to contribute a rule for it :-)
Might that be a PowerShell based rule? (FYI: I don't have enough C# known to write something like that in C#)
Agree with it, feel free to contribute a rule for it :-)
Might that be a PowerShell based rule? (FYI: I don't have enough C# known to write something like that in C#)
To be included with PSScriptAnalyzer, it would be C# because PowerShell based ones are too slow and CPU intensive to run by default for the millions of PSSA users. Alternatively you could write your custom PowerShell rule and open source it for the community to use.
@DrSkillIssue,
Thank you for picking this up!
I was about to write a rule in PowerShell but wasn't ably to do more than just some preparation before my holidays last 2 weeks.
As this rule requires you to resolve the existence af a specific parameter which I needed to be able to do before and I (incorrectly) did in e.g. my AvoidDynamicVariables.psm1 rule. Therefore I decided to ask the specific question: How to resolve command name and parameters from a CommandAst.
And apparently I didn't do this very well as there is indeed a good method that can do this for you, thanks to Santiago Squarzon's helpful answer
My C# skills are very poor, but I quickly tried to understand your code and I believe you don't use this bindcommand method either which I think would be better to use for this knowing that the -ComObject might be (0) positioned or provided elastically, like: New-Object -Com InternetExplorer.Application.
@iRon7 Oh! I didn't know that existed. I'll definitely use this for future rules. However, StaticParameterBinder wouldn't be of use for Parameter Splats as you still have to search for what keys are within said Parameter Splat. In other words, unfortunately wouldn't make the code easier to understand as you still have to hunt for variables.
You are correct that I missed Parameter abbreviations. I'll readjust the logic for that. Good catch as I'm always typing out full parameter names and that slipped my mind.