Modified indentation policy for wrapped expressions (with focus on conditions)

[orenbenkiki]

📋 Description

This is something I have used in my C code back in the 80s and have been struggling to get code formatters to do ever since (with varying levels of success).

The general rule is: indent the wrapped lines so that operands at the same level in the expression tree have the same indentation; nested operations are "more indented". For best results, when wrapping long lines, parenthesis are always used to clarify the evaluation order and ensure "nested" operations are more indented. This makes a lot of sense for boolean operators anyway (quick, what does a && b || c do?).

For example, in if statements:

if some_condition
&& another_condition
{
    code...
}

if (some_condition
 && another_condition)
|| yet_another_condition
{
    code...
}

if (some_condition
 && another_condition)
|| (yet_another_condition
 && final_condition)
{
    code...
}

This makes the structure of the condition very clear. Compare with the current formatting where the indentation level is actively misleading:

if some_condition
    && another_condition
{
    code... // is indented the same level as the condition, so wasting a line for { is required
}

if (some_condition
    && another_condition)
    || yet_another_condition
{
    // Misleading, another_condition and yet_another_condition have same indentation
}

if (some_condition
    && another_condition)
    || (yet_another_condition
        && final_condition)
{
    // Misleading again; also, symmetric structure of statement is not apparent
}

The proposal generalizes to while statements as follows:

while some_condition
   && (another_condition
    || yet_another_condition)
{
    code...
}

Ideally, I'd love to see this approach be extended to wrapping long expressions in general:

fn foo() -> bool {
    let bar = some_condition
           && another_condition;
       some_condition
    && another_condition
}

And apply this to other operators as well:

fn foo() -> usize {
    let bar = some_value
            + (another_value
             * yet_another_value)
            - final_value;
      some_value
    + (another_value
     * yet_another_value)
    - final_value
}

[calebcartwright]

Thanks for reaching out with your suggestion and accompanying examples!

As you may already be aware, rustfmt's purpose is to reformat/check code according to the official Style Guide. The various style rules and their respective merits and drawbacks were debated at length and then ultimately codified. Configuration options are also supported to cater to cases and users where there's a desire to produce formatting that diverges from that Style Guide, primarily focused on some of the topics developers tend to find more contentious (tabs vs. spaces, brace placement, etc.).

Most of the time we're open to considering new configuration options if there's sufficient justification and someone from the community is willing to submit a PR, but we do still have to consider whether the impact of the changes on the codebase and subsequent maintenance/increased bug surface/etc. are acceptable in the context of the configuration option/non-default style.

We definitely cannot change the default/primary formatting style to your proposed style, so it could only potentially be supported with such a configuration option. I don't expect anyone on the rustfmt team would ever get around to considering implementing such a configuration option, but if you or anyone else is interested in working on an implementation then we'll certainly take it into consideration.

[orenbenkiki]

Changing the default style is indeed way too aggressive. Having it as an option though...

It would be "non trivial" to implement this (I have no familiarity w/ the rustfmt code base), so it would only make sense if there's a reasonable chance of it being acceptable as an option - glad to hear this might be the case.

[calebcartwright]

I agree it would likely require a non trivial implementation. To be fully transparent I suspect that such indentation/alignment would require a pretty invasive set of changes across swaths of the codebase which would be a potential point of concern.

Would be happy to be proven wrong though if anyone wants to take a pass. It's definitely a possibility but would really boil down to the implementation.

[ytmimi]

feels somewhat related to #3108