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