Comments in else if are formatted *really* poorly

[ag-eitilt]

    # Don't run any tests if the help argument is present
    if helpArgumentPresent then
        Pass "No tests ran"
    else
        # Check if the print failures flag is present. Both "-p" or "--print-failures" are
        # checked by the following query given the definition of the print failures argument
        # in the parser definition.
        if isArgumentPresent printFailuresArg parsedArguments then
            unitTestResults ("print_failures", Nil)
        else
            unitTestResults Nil

gets formatted as

    # Don't run any tests if the help argument is present
    if helpArgumentPresent then
        Pass "No tests ran"
    else 
    # Check if the print failures flag is present. Both "-p" or "--print-failures" are
    # checked by the following query given the definition of the print failures argument
    # in the parser definition.
    if isArgumentPresent printFailuresArg parsedArguments then
        unitTestResults ("print_failures", Nil)
    else
        unitTestResults Nil

I'm not only surprised that having the second if at the same indentation as the first else works (or, at least, the LSP doesn't complain), there's actually a trailing space added after the first else. This should probably just formatted identically to how it originally was (indented and no trailing space).

[V-FEXrt]

Ignoring the specific challenge of implementing this, I would strongly advise (in fact I'll probably add it to the lint rules) that comments don't split else if.

While the runtime sees else if as just an if/else inside of an if/else that isn't how it reads nor how most of our users would think about it. Most users would consider else if a non-splitable construct and I think we should encourage the same

[V-FEXrt]

hmmm :/ that said I suppose putting the comments above would also look bad if the formatter does what I think it would do

    # Don't run any tests if the help argument is present
    if helpArgumentPresent then
        Pass "No tests ran"
        # Check if the print failures flag is present. Both "-p" or "--print-failures" are
        # checked by the following query given the definition of the print failures argument
        # in the parser definition.
    else if isArgumentPresent printFailuresArg parsedArguments then
        unitTestResults ("print_failures", Nil)
    else
        unitTestResults Nil

not sure, need to test it

[ag-eitilt]

Most users would consider else if a non-splitable construct and I think we should encourage the same

Definitely agree with that, but if they've already put a comment in between there, and especially given the line-breaking required, it seems like they aren't considering it an else if but instead an else containing an if. Or do we run into problems with it seeing that construct identically to else if b then # comment?

If the formatter is indeed able to distinguish them move only intervening comments to the previous line, with the proper indentation, then I definitely agree that's the best formatting (and is how I fixed this example in the actual code), but then we have the question of

if a then
    ...
# something explaining the `else`
else
    # something explaining the nested `if`
    if b then
        ...
    else
        ...

[JakeSiFive]

Don't nest elses like that, treat "else if" as a keyword. If you have a larger block then the formatting won't work break when you do that.

[ag-eitilt]

If I remember the sequence of events here, the else case originally contained a def, followed by a comment describing the second if...else block which used the def. Refactoring allowed me to get rid of the def, and I didn't think about joining the two because it was (A) not originally my code, and (B) was conceptually a separate block before a conceptually non-structural change. I definitely agree that this sort of structure isn't desirable and should probably be flagged in code review, but I don't actually see ideal style as being particularly relevant to this issue -- at least, assuming we can't find a good way to have the formatter move the comment, which would be the best choice.

Whether it's a good idea or not, it is technically possible to add a comment between an else and a following if, and it isn't actually all that tricky to do so (see: my winding up with that layout by accident). If the formatter can make the code better, then it should definitely do so, but at a baseline it shouldn't make the code worse, barring technical reasons of not being able to read developers' minds. In this case, de-indenting the second and third clauses is making it worse, and we can get a reasonable idea of what the developer was thinking because of the requirements having a comment in that location necessarily imposes. We can definitely discuss what the resulting code should look like, but discussion of what the input code should look like doesn't stop edge cases from happening.