Allow defining command options without a name

[Tyrrrz]

I think we can relax the requirements around command options, more specifically let the user specify them without a name. A default name should be generated based on the property name. This should make it easier to quickly hack a prototype without spending too much time on naming options.

The default name generation logic is as follows:

1. Take the property name
2. Insert dashes between word breaks (identified by a lowercase character followed by an uppercase character)
3. Lowercase it

Examples:

// Name defaults to "foo"
[CommandOption]
public string Foo { get; set; }

// Name defaults to "foo-bar"
[CommandOption]
public string FooBar { get; set; }

Unlike regular names, short names should never be set unless explicitly provided.

Note: some analyzers or tests may need to be updated.

[dcarpenter31]

Hi, I've been working on potentially resolving this issue and I have a question about the analyzer. With this update, the diagnostic report that warns that options require names will become obsolete, right? Do you want that diagnostic to be simply deleted, or is there a more graceful way to handle it since the diagnostics are numbered? Apologies, I have never worked on a project with analyzers before.

[Tyrrrz]

Hi @carpenterd777.

That's correct, that analyzer can be deleted.

[dgarcia202]

Created a pull request for this one #95

hope it is useful :)

[Tyrrrz]

Decided against implementing it because of potentially ambiguous or unintuitive behavior:

1. Name is provided → name is set to provided value (✔️)
2. Name is not provided, and short name is not provided → name is derived from property (✔️)
3. Name is provided, but short name is not provided → name is derived from property (✔️)
4. Name is not provided, but short name is provided → unclear what should happen (❓)

Also, the fact that parameter order cannot be derived automatically no matter what we do hurts overall consistency too. Even if we can try to derive parameter order from property declaration order (which is unintuitive when base types are involved), it's unclear what should happen when some parameters have order specified while others don't.

Finally, when automatically inferred values are involved, catching mistakes with analyzers is much harder because the same resolution logic has to be performed there as well.

Ultimately, I think having name and order provided explicitly is both simpler and leads to better developer experience, albeit with a bit more writing.