Skip to content

Use explicit MatchData captures instead of regex globals#43

Open
tas50 wants to merge 1 commit into
chef:mainfrom
tas50:cleanup/regex-captures
Open

Use explicit MatchData captures instead of regex globals#43
tas50 wants to merge 1 commit into
chef:mainfrom
tas50:cleanup/regex-captures

Conversation

@tas50

@tas50 tas50 commented Jun 28, 2026

Copy link
Copy Markdown

Summary

SubscribesMatcher and NotificationsMatcher parsed their type[name] signature by calling String#match purely for its side effect and then reading the magic $1 / $2 global match variables:

signature.match(/^([^\[]*)\[(.*)\]$/)
@expected_resource_type = $1
@expected_resource_name = $2

The $1/$2 globals are implicit, thread-local-but-easy-to-misuse state that's brittle if any other match runs in between. Capturing the MatchData in a local and reading match[1]/match[2] is clearer and self-contained, with identical behavior.

Testing

  • bundle exec rspec spec/unit/matchers/subscribes_matcher_spec.rb spec/unit/matchers/notifications_matcher_spec.rb7 examples, 0 failures.
  • bundle exec rspec spec/unit/162 examples, 0 failures.
  • cookstyle --chefstyle -c .rubocop.yml → no offenses.

SubscribesMatcher and NotificationsMatcher parsed their `type[name]`
signature by calling String#match for its side effect and then reading
the `$1`/`$2` global match variables. Capture the MatchData in a local
and read match[1]/match[2] instead — clearer, thread-safe, and not
dependent on hidden global state.

Signed-off-by: Tim Smith <tsmith84@proton.me>
@tas50
tas50 requested review from a team and jaymzh as code owners June 28, 2026 05:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant