string-format: Missing possibility to consider matches as linting errors

[nachtjasmin]

Is your feature request related to a problem? Please describe.
Since Go (or at least the RE2 parsing engine) does not support negative lookaheads in regular expressions, it's hard for me to exclude certain strings in the string format.

Right now, I want to check for the things inside the fmt.Errorf call:

1. Does not contain phrases like "could not", "error" or similar.
2. Verbs are using the present tense instead of the continuous tense (e.g. "do" instead of "doing").

Both solutions are fairly easy to implement with regular expressions.

1. /(could not|error|failed)/
2. /(\w+ing)/

Examples:

• valid: create API client: %w
• invalid: creating API client failed: %w:

Unfortunately, the current revive rule asserts: If the pattern matches, this is valid code.
But I need: If the pattern matches, this is a linting error.

Describe the solution you'd like
There should be a way of defining expression rules that should not appear in certain strings. So, if the pattern matches, this is considered a failure.

Describe alternatives you've considered
"Invert" the above regular expressions. In my opinion that's way too complicated for such a simple case.

[chavacava]

Hi @chloe-the-catgirl, thanks for filling the issue.

Does negating the regular expression in the configuration could work for you? For example by adding a ! in front of the regular expression:

[rule.string-format]
  arguments = [
    ["fmt.Errorf[0]", "/^([^A-Z]|$)/",  "must not start with a capital letter"],
    ["panic",         "!/^([^A-Z]|$)/", "must     start with a capital letter"]]

Then your example could be written as:

[rule.string-format]
  arguments = [
    ["fmt.Errorf[0]", "!/(\w+ing)/",  "must not use the present tense instead of the continuous tense"],

You can test by checking-out https://github.com/mgechev/revive/tree/feature/762

[nachtjasmin]

Hi @chavacava, thanks for the quick response ☺️
That would be perfectly fine as it covers my usecases perfectly with a clean syntax. Really like the approach! 😄