I don't think the leading \ does anything, since it just acts as an escape, and - doesn't need to be escaped at the beginning of a regexp. It only acts as a regexp separator when it's between two characters. I'm also fine with keeping it though, just to be explicit

Well spottet, @cllns !

Actually, I quote - inside square brackets always and on purpose: Not everybody is experienced enough with Regexp to know and if you add another acceptable character to the front of the list, the unquoted - silently flips from being a literal to a range operator. And if this someone is out of luck, the resulting range includes the literal - and therefore the tests might not even fail. This quite likely wouldn't be a huge problem here, but it could introduce a difficult to spot bug or even open a security gap elsewhere. Thus, better safe than sorry.

But feel free to insist or change it if you prefer dropping the quote.

Can we remove this and just comply with the rule instead? It's not as clean looking but it's still fine, especially since this is just a spec

Sure thing, removed it.

It doesn't look like prefixed_name is used anywhere else, and it's defined as a private method + private API, so can we just push the underscoring into that method? It'll save some coercion back-and-forth between symbol and string, but more importantly, it keeps thing simple and doesn't overly abstract helper methods.

Absolutely, it now reads:

    def prefixed_underscored_name(name)
      @name_prefix
        .relative_join(name, PREFIXED_NAME_SEPARATOR)
        .gsub(UNDERSCORED_NAME_REGEXP, "_")
        .to_sym
    end

Hope, the multi-line notation with leading dots is okay, opinions and tastes differ on this one.

Rubocop appears to be okay with it, but it barks at the constants being declared following private:

Useless private access modifier for constant scope.

How do you deal with such situations?

• Move private or exclude the cop rule?
• Mop this up as part of an existing PR like this one or create a fresh PR for it?