Tell SimpleCov to ignore unreachable code

[bquorning]

In some cases we know that a case statement is covering all possible branches, e.g. case [foo?, bar?] has four branches (if the predicate methods return booleans, of course), and case style has a know number of branches, depending on SupportedStyles in config/default.yml.

So, when to use else ... raise ArgumentError, and when to change the last elsif or when into an else? I don't know.

To avoid conflicts with other PRs improving code coverage, the .simplecov file is not updated here.

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[bquorning]

cc @corsonknowles

[corsonknowles]

I like the use of else blocks!

I agree it's a good sign to be deliberate that it's unreachable code.

At this point, I think we should probably add a contributor guideline to the README so folks know how to handle unreachable code.

Some ways of using node patterns and then further matching in Ruby methods and case handling for config both lend themselves to that outcome, so it will likely come up.

[corsonknowles]

Also FYI, I tried in blocks instead of when blocks for exhaustive pattern matching, and although they work great, they do not change the coverage issue:
https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rdoc.html

[bquorning]

I like the use of else blocks!

else is easy, but e.g. when :be_falsey, :be_falsy, :a_falsey_value, :a_falsy_value or when [false, false] is more informative, almost serving as a kind of documentation. Which is why in some places I kept the list of possible values as a comment, and in other places chose to add an else branch that just raises an exception.

[bquorning]

If I remember correctly, case/in blocks must have an else branch. Or is it just that it raises an exception if none of the branches are matched?

[corsonknowles]

It raises an exception NoMatchingPatternError. This essentially handles that part for us (instead of ArgumentError), but it's not considered exhaustive. It also doesn't give us a convenient place to put a `# :nocov` block. Not considering the `case ... in` block to be exhaustive may be a failing in Simplecov that we should look into, since pattern matching is new but not that new.

…

On Sun, Feb 9, 2025 at 7:19 AM Benjamin Quorning ***@***.***> wrote: If I remember correctly, case/in blocks *must* have an else branch. Or is it just that it raises an exception if none of the branches are matched? — Reply to this email directly, view it on GitHub <#2034 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANFDS2Y5QPC6YCEHI6DYRL2O5WYHAVCNFSM6AAAAABWYZY3Z2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNBWGM2TGNBQGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bquorning]

@corsonknowles Yay ✨

[pirj]

🤩👏

[corsonknowles]

❤️ 🥇

[bquorning]

@pirj 👍🏼❓

[pirj]

Thank you! 🤩