Rubberduck: Cant rename standard module to something which includes a "-"

[Gener4tor]

This might already be known but I could not find how to search known bugs:

When I try to rename standard module "Z-ObjectFactory" to "Z-Object-Factory" (or the other way around) the ok button in the rename-dialog is not enabled.

Its seems like rubberduck dont want me to use "-" in any module name while ms-access has no problem with this.

[bclothier]

While dashes are legal, they would require the name to be bracketed:

Module-1.x() 'Syntax error
[Module-1].x() 'OK
Module_1.x() 'Doesn't need bracketing
Module1.x() 'Neither this

Wouldn't you rather have names that doesn't require bracketing?

[Gener4tor]

This is a standard module so I usually dont want to use the module name anyway. I use "x()"...

And this is not a matter of choice. If there are tons of legacy code which work with exactly this naming convention then its not as easy to change.

Anyway: Rubberduck should not try to force me to do things just because it thinks its better for me.

[MDoerner]

I agree that we should allow all legal names that do not cause a conflict with an existing name.

Still, I would suggest to ask the user for confirmation for choices that require brackets in code.

[bclothier]

Currently the code for validating the name looks like this:

https://github.com/rubberduck-vba/Rubberduck/blob/e5baebd879f0846e42b0aa76fa6bb299bffc8efb/Rubberduck.Core/UI/Refactorings/Rename/RenameViewModel.cs#L66-L70

The line !NewName.Any(c => !char.IsLetterOrDigit(c) && c != '_') is a bit too restrictive.

We most likely need a separate property IsRestrictedName which will then present the user with a yellow exclamation icon instead of red cross icon and thus bring the attention to the user that the name is legal but would require bracketing.

[MDoerner]

I think what we actually need is a different validation for modules and maybe projects. For declarations defined in the code, the restriction is completely valid.

[comintern]

This is host specific. From 3.3.5 Identifier Tokens:

Implementations MUST support <Latin-identifier>. Implementations MAY support one or more of
the other identifier forms and if so MAY restrict the combined use of such identifier forms.

In Excel, identifiers containing - are illegal, so implementing this would require name validation for each VBA host. If this _is_ implemented, I'd propose adding a NonPortableIdentifierInspection that would flag uses of identifiers that fall into the "MAY" category of the specification.

[daFreeMan]

"that would flag uses of identifiers that fall into the "MAY" category of the specification."

I think it would also make sense to warn against using them because of reasons (as specified in chat).

[bclothier]

Because it's host specific, and I really don't want to have to enumerate each host's specific extensions, I'm inclined to stick to a modified version of the original proposal - provide a yellow exclamation icon for any identifiers that bucks the absolute minimum as specified in 3.3.5 (which is any latin characters), along with a try/catch in applying the change with notifications to the user if the change is rejected by the host.