Powershell: Verbs range in Get-Verb is very limited. Allow users the flexibility to add more meaningful verb names for doing their jobs without getting warnings in IDE.

[PramodKumarYadav]

Summary of the new feature/enhancement

As an end-user, I want to be able to name my functions as most appropriate for the job without getting any warning in my IDE (Such as VSCode). Ex: Sort-JSON or Download-Results or something else without getting warnings.

Summary of issue

As a user building test automation framework, I want my PowerShell function names to be intuitive and relevant for the job in hand rather than having to mold my function names to meet the approved verb list standards (to avoid warnings in my IDE). So say Get-SortedJSON or Import-Results from above example.

Many a time, while building our test framework, I and my buddy find that we don't have the right verb for the job in hand. We try to adjust to the verbs available (since we don't like those warnings), but we know that another verb would have been a better choice in helping us remember what exactly that function does. Should you provide an option to users to add new verbs in the approved list so that we don't get warnings (say in vscode for example).

I am sure as end-users there are more people who would love to name their command's as they find most appropriate for them rather than a restrictive list that cannot be extended. Sort is one example, Download is another, FTP could be another, the list goes on depending on what we want to do with a function.

Proposed technical implementation details (optional)

One of the solutions could be to allow users to add a new verb to the list of approved verbs in Get-Verb list that works on their local machine without warnings. So something like Add-Verb.

This will have issues that when one user shares a script with another user, it will show those command names as warnings in other users' machines. Maybe you can think of a good solution to handle this issue? Or you can come up with a better/different solution.

As long as an end-user, I am able to name my functions with the appropriate verb for my job without getting any warnings. How you implement it then wouldn't be my concern as an end-user.

Examples are already shared above, so I skip this part.

[iSazonov]

Sort verb discussion https://github.com/PowerShell/PowerShell/issues/3370

[vexx32]

Of particular relevance to the immediate issue here is @SteveL-MSFT's response in the issue @iSazonov linked: https://github.com/PowerShell/PowerShell/issues/3370#issuecomment-514758996

FWIW I agree; the approved verbs list is designed to standardized command naming to a minimal set in order to make discovering commands easier.

Personally, I've also found that it lends itself to encourage authors to design commands in a more consistent and predictable pattern, so there's less guesswork involved when working with a new module.

From the examples mentioned in the issue description, I have a couple thoughts.

1. I would use Get or Import (depending on the purpose) verb for anything you're considering using 'Download' for.
2. I'm not really sure why sorting the JSON is important as typically the order of properties is not important. If it is, you could use a Get or perhaps ConvertTo verb there. That's a fairly uncommon edge case in my opinion. Typically Sort-Object is more than sufficient.

[PramodKumarYadav]

Well, I took Sort and Download as an example but the restriction that we feel is not limited to these two. So limiting the discussion to these two would be missing the point that users like to have the freedom to name their functions as they find most apt.

If the goal is to make discovering commands easier, maybe PowerShell team can come up with a smarter way to deal with this where users can have their freedom and PowerShell could still discover the commands? I don't know you are the smart guys in this area. I am someone who is just a user and loves using it.

P.S: To answer your points, sorting JSON becomes important if I have to create an automation suite where I have to validate an asynchronously created JSON output with an existing snapshot. If I don't sort them on a key, I will be validating apples with oranges. And although I am using Get/Import for Download but every time I do that neither I nor my partner is happy about it since we are wrapping our obvious intent under something more generic as get/set etc.

[SteveL-MSFT]

If VSCode (or rather PSScriptAnalyzer) is the annoyance, you can always suppress specific errors (in your script) or create a settings file for PSSA to ignore the invalid Verb rule. If there is a common verb that will be used and should be an approved verb, we are open to adding them. However, as @vexx32 pointed out, one of the design philosophies of PowerShell is consistency.

[iSazonov]

For information https://github.com/PowerShell/PowerShell/issues/3346

[jhoneill]

There is a standard list of verbs, if something is missing there should be a fairly high bar to get over. 4 have been added since PowerShell 2 in 2009 (Optimize and Resize sometime before 5 and Build and deploy for 6).
It seems odd to me that when you check the cmdlets for things which don't use a standard verb you get:

Name                             Source
----                             ------
Delete-DeliveryOptimizationCache DeliveryOptimization
ForEach-Object                   Microsoft.PowerShell.Core
Sort-Object                      Microsoft.PowerShell.Utility
Tee-Object                       Microsoft.PowerShell.Utility
Where-Object                     Microsoft.PowerShell.Core

Delivery optimization has got it wrong. There are Clear, remove and reset verbs. You don't delete a cache but it's entries. (and in the original question, Download ... is either a get or a copy operation. )
You can't really Tee anything but an object.
But I only half see the logic of reserving foreach, sort and blocking sort-userList, or sort-Json,

As time has passed I have moved more towards making private functions in a module (or nested functions inside another function or a script) use single word names, and keeping verb-noun names for what is seen by the outside world (scripts too benefit from proper naming).
non-compliant-Name <==> private / compliant name <==> public is useful.

[yecril71pl]

Anything that applies to Object is reserved because it applies to any object, be it a user list, JSON, or a yellow submarine.

[jhoneill]

Not quite anything
````
$v = get-verb | select -ExpandProperty verb

508 PS7 C:\Usersmcp\Documents\WindowsPowerShell>get-command -noun object | where verb -in $v

CommandType Name Version Source
----------- ---- ------- ------
Cmdlet Compare-Object 7.0.0.0 Microsoft.PowerShell.Utility
Cmdlet Group-Object 7.0.0.0 Microsoft.PowerShell.Utility
Cmdlet Measure-Object 7.0.0.0 Microsoft.PowerShell.Utility
Cmdlet New-Object 7.0.0.0 Microsoft.PowerShell.Utility
Cmdlet Select-Object 7.0.0.0 Microsoft.PowerShell.Utility
```
The logic probably does work the other way around. Reserved verbs apply to any and all object types.

[yecril71pl]

New-Object does not apply to Object, in spite of its name.
Select-Object applies to objects but it does not select them, another misnomer. Select-SubObject would be a better name.
(Aside: Select-String does not apply to strings, at least not in the default parameter set.)
Compare/Measure-Object do not apply to objects, they apply to collections. Measure is a particularly bad name for this action, it should be Summarise; Measure itself should be free to use.
I agree that Group could be reserved together with Sort, since they are different aspects of the same concept. However, Group can also mean Partition—and partitions may be fuzzy while sorting cannot. You cannot make fuzzy groups of objects but you can make fuzzy classes of seeds. It is a different action expressed with the same verb. If we reserved Group and introduced Classify or Partition, it would resolve the ambigüity.
There is, however, one use case for a specific Sort: when the data you need to sort do not fit into available memory, you need to sort them in place. But then you probably would not use PowerShell to do it anyway 😁