Editorial: Avoid preceding a multi-step Else with a collapsed single-step If

[gibson042]

We have a few cases of algorithms with steps like

1. …
1. If <condition>, <simple consequent>.
1. Else,
  1. <alternative step 1>.
  1. …
1. …

This makes it unnecessarily difficult to track expected behavior, especially when skimming, and I think the spec should have a convention (ultimately codified as a lint rule) to avoid mixing collapsed an non-collapsed steps at the same level of an If–Else construct.

The first commit of this PR replaces violations of that convention, and later commits (removable upon request) PRs #3044, #3045, and #3046 apply simplifications in the neighborhood of its changes.

[michaelficarra]

I like all of these, but I would prefer they each be separate PRs. Please remove all but the first commit from this PR and I'll approve.

[michaelficarra]

Nice. @bakkot Could we add an ecmarkup lint rule for this?

[syg]

lgtm, I agree with this stylistic convention.

To preempt: I very much like single-line 1-armed ifs and would be opposed to changing those.

[jmdyck]

I believe this PR handles all the cases outlined in the description.

In addition to those, the spec has some similar cases that the editors might also like 'fixed'. (But I'm not saying that needs to be done in this PR.)

• 10 cases where, between the collapsed single-step If and the multi-step Else, there's a single-step Else if.

• 2 cases (NumberBitwiseOp, ByteListBitwiseOp) where single-step If/Else if is followed by:

  1. Else, _op_ is `|`. Let _foo_ be ...
  

  which would be a multi-step Else if we expressed it as

  1. Else,
    1. Assert: _op_ is `|`.
    1. Let _foo_ be ...
  

  (similar to what we do in BigIntBitwiseOp).

• 23 cases where the imbalance is the other way around: a multi-step If followed by a single-step Else or Else if.

[michaelficarra]

@jmdyck Yes, I would like all of these addressed.

[jmdyck]

@jmdyck Yes, I would like all of these addressed.

In this PR or a separate one?

[bakkot]

Fixes for all of those are in #3048. The new lint rule caught all of them (as far as I can tell) other than the NumberBitwiseOp / ByteListBitwiseOp cases, which I addressed manually.

[michaelficarra]

Closing in favour of #3048.