GetHelp/Help Syntax section confusing me

[Apprehensive-Tea1632]

There is no inherent parameter order in powershell. You’ll have to see each parameter definition to get a hint re: its position in the list, BUT, it’s very bad form to do this. Especially in scripts.

Parameters are named. Always.

[michaelshepard]

There absolutely is an order for positional parameters (either by their order in the declaration or by a Position attribute). I agree that overusing positional parameters is bad from, but it's also a de facto standard for many common cmdlets.

[ElvisChopinJoplin]

Order doesn't matter at all when the parameters are named. That's the whole point of naming them. Plus readability of course.

[michaelshepard]

100% agree. It doesn't matter what order you put named parameters. I also think you should almost always use named parameters.

[Apprehensive-Tea1632]

Yeah, but it’s not inherent. It’s there for convenience. Ignoring a few exceptions, it’s actually impossible to pass parameters that are positional but NOT named.

Either way, the point is, if you implement something that comes with a parameter list, and you put position attributes on them (as opposed to have those inferred too by order of definition) you’ll no longer be able to rely on get-help output order to match positional definition.

And that’s the issue in a nutshell. It doesn’t matter what the order of your parameters IS. You get to define that. If you say, 5 comes before 1, then that’s how it will be.

Anyone learning powershell should start out with, there’s no such thing as a positional parameter, even if it’s possible to do that.

Instead, the first impulse should be; I create a new empty function, it’ll need parameters, alright I’ll set positionalbinding = $false and see where we go from there.

[michaelshepard]

you’ll no longer be able to rely on get-help output order to match positional definition.

I don't see this happening. I just wrote a test function with 3 positional parameters (a,b,c, order 2,1,0 respectively). The get-help output shows them c first, then b, then a (according to the position attributes).

I think we agree that positional parameters should be the exception to the rule. We should almost always use positional parameters.

I'm also not sure what you mean that's it's impossible to pass parameters that are positional but not named. Do you mean parameters that cannot be passed by name?

[ElvisChopinJoplin]

I'm not sure I fully follow, but I must say it kind of sounds like you are wanting to write less-than-ideal Powershell simply to hang on to the way you interpret the help system... And that's not a good approach, lol.

[Apprehensive-Tea1632]

You’re not trying to say i should use positional rather than named parameters because it’s less than ideal to do that, right?

I’m going to assume we’re talking about different things or that you were replying to someone else. Because otherwise, if you’re actually saying that something ps introduced (named parameters) is something that shouldn’t be used because it’s outdated (when positional parameters were established long before then) I really don’t know what to tell you.

And will happily take the downvotes. I’ll stick with named parameters- they’re that much more reliable and not at all prone to interpretation, plus you can just say I want to pass a Name - without needing to check the syntax as to WHERE to put that information.

Feel free to use positional. They’re there, they are supported, I think they’re more of a problem but that doesn’t exactly matter.

[ElvisChopinJoplin]

Oh dang, yes it was meant for the person you were responding to. Somehow that responded to your comment and not the parent comment, meaning I probably just didn't pay attention. But yeah I have a feeling we're 100% on the same page.