Make Annotation Syntax Configurable

[retailcoder]

Justification Our grammar makes annotation legally parameterized with or without parentheses, and @Folder annotations for folders that are legal PascalCase identifiers are legal with or without the " double quotes. Currently the "annotate" command generates the non-parenthesized syntax (it also changes parenthesized syntax to non-parenthesized), without any way for the user to change the generated code before it's generated.

Description Let's add a PreferredAnnotationSyntax configuration setting (and default it to non-parenthesized, to maintain the current default behavior) in a new AnnotationSettings settings tab.

The possible values could be:

• QuotedNoParens / '@Annotation "argument" - current default, surrounds the arguments with " double quotes, without parentheses (always safe).
• QuotedParens / '@Annotation("argument") - surrounds the arguments with " double quotes, with parentheses (always safe).
• NoQuoteNoParens / '@Annotation argument - avoids surrounding arguments with " double quotes if possible, without parentheses. Quotes can still be added if the argument (as parsed) contains spaces.
• NoQuoteParens / '@Annotation(argument) - avoids surrounding arguments with " double quotes if possible, with parentheses. Quotes can still be added if the argument (as parsed) contains spaces.

The annotate command will need to be amended to listen for configuration changes and update its annotation-generation mechanics accordingly; the user preference may need to be overridden if they prefer no quotes but the argument contains spaces (I know that breaks the @Folder annotation, haven't checked others).

Another KeepExistingAnnotationSyntax setting (checkbox/Boolean) would override all of these, in cases where the annotation already exists. Turned on, that would make the command keep whatever syntax is currently being used when rewriting existing annotations. Turned off (should be the default, to maintain current default behavior), it would make the command use the preferred syntax when rewriting existing annotations.

[bclothier]

FWIW, having variants doesn't sit well with me. It's kind like saying "you can drive on the left or you can drive on the right, it's your choice." The choice of which side to drive on is entirely consequential but by golly, everyone better drive on the same side if they want to avoid a head-on collision.

For that reason, not having variants is the better choice in my mind. Rubberduck ought to have only one variant; with or without parentheses (though my vote is for with but that's just me) and given that we already enforce it when it is updated, it seems preferable that we avoid the problem altogether by emitting only a single variant but allowing reading of variants for backward compatibility. AC can be eventually leveraged to "auto-correct" the variant into the preferred syntax to help hasten the obsolesce of the variants from the grammar.

[daFreeMan]

I'm generally all for user options, but I'm actually tending to agree with @bclothier on this one. I just looked at the 2 modules I've got open in my Excel project at the moment and I've got ("x") and "y" formats in the two. Because I didn't know which one is "correct" and the duck just accepts both, I'm not sure which is preferred to use in my next module.

TBH, though, it seems like the Tabs v Spaces argument: Go with whatever your local coding standard is and live with it because in the long run, it really doesn't matter. Set the standard in the Duck's options and move on (so long as there's an option for the Duck to "fix" anything that doesn't match the selected option).