Multi condition case when

[NewAlexandria]

Depends on Chanel #9

Following-up from the PR on When/Then block

There is no demonstration to confirm how to format when multiple conditions should result in the same action. I propose this:

# good case token when :star_op stack.pop * stack.pop when :slash_op stack.pop / stack.pop when :minus_op, :minus_minus_op also_calculate_that stack.pop - stack.pop when MyModule::SomeDomain::BETA_USERS, MyModule::SomeDomain::INTERNAL_RELEASE stack.pop + stack.pop when :int_literal, :some_complicate_explicit_name, :graduate_borrowers_with_arms, :str_interpolated token.value end

Though better control of primary domain references should be exercised, this style offers a solution for some 'in the wild' situations. It reads better than:

# bad case token when :star_op stack.pop * stack.pop when :slash_op stack.pop / stack.pop when :minus_op, :minus_minus_op also_calculate_that stack.pop - stack.pop when MyModule::SomeDomain::BETA_USERS, MyModule::SomeDomain::INTERNAL_RELEASE stack.pop + stack.pop when :int_literal, :some_complicate_explicit_name, :graduate_borrowers_with_arms, :str_interpolated token.value end

Where the 'bad' example also has the issue of cause the entire when line to diff when one of the conditions is changed or updated.

I know that some people love long lines, but I suggest that a newline is an easier-to-cognized demarcation of conditions, rathe than a comma

[freemanoid]

I believe you should update your PR considering the rule "Indent when as deep as case"
Correct version:

# good case token when :star_op stack.pop * stack.pop when :slash_op stack.pop / stack.pop when :minus_op also_calculate_that stack.pop - stack.pop when :plus_op, :plus_plus_op stack.pop + stack.pop when :int_literal token.value end

[bbatsov]

The suggested rule is pretty subjective IMO - I don't see any notable readability improvements. I should also point out I've never seen it in the wild and I've been programming in Ruby for quite a while.

[freemanoid]

@bbatsov what is your suggestion for when statement with many conditions when it can't fit in one line?

[bbatsov]

@bbatsov what is your suggestion for when statement with many conditions when it can't fit in one line?

Break them up as suggested here, of course. My problem with this PR is that it suggests doing this all the time.

[freemanoid]

As for me it's an obvious way to split conditions as suggested here but I believe that style guide must be explicit. We can add this rule with the note that it should only be used when conditions doesn't fit in one line. What do you think?

[bbatsov]

What do you think?

Fine by me.

[NewAlexandria]

I've pushed an update to correct the indentation mistake.

I also tried to be more clear with in the wild situations that I've seen the need for this. I've actually been at more than one company that needed this formatting in the codebase.

I think it's lovely to imagine that every team is going to be agile and lean enough to get onboard with refactoring that can demonstrably improve maintainability. Sadly many orgs have complicated dependencies and Dilbert-grade managers. This part of the style guide helps in these situations.

I changed the examples to be permissive of short condition-groups that can stack and remain readable immediately — which I hope allays the concerns raised by those who do not often encounter the situation.

[freemanoid]

Why there're so many changes in PR? I believe you should include only multi condition changes in this PR. Could you explain it?

[NewAlexandria]

woof, I don't know what all other others are; let me rebase. The only real commits here are

• 7f60efe
• ad68059
• c68632c

[freemanoid]

Could you cherry-pick these commits and squash them? I think it will help to merge this PR sooner.

[NewAlexandria]

there we go 👍

[freemanoid]

According to other rules in the guide:

1. The sentence must be capitalized and end with a dot.
2. Good and bad examples usually combined into single code snippet.

[NewAlexandria]

sure

[NewAlexandria]

I've updated the good example to show both

• all-on-one-line cases (when they are easy to read)
• multi-line cases (when they are too-long, as discussed above)

[NewAlexandria]

Is there more I can do to make this conformant with the ideals of this repo?

[NewAlexandria]

Replaced by #741