Disable exact checking of multi-line chained method calls in Generic.WhiteSpace.ScopeIndent

[pfrenssen]

I'm preparing to adopt a coding standard that is based on PSR-2 and the upcoming PSR-12. The standard will require an exact indentation of 4 spaces. In the current implementation of the PSR-12 ruleset the exact checking of the Generic.WhiteSpace.ScopeIndent is disabled because this option is incompatible with some custom indentation rules. The documentation mentions that the option is not recommended to be used.

However in my testing it appears that with the recent fix of [#2281] the exact indentations work pretty well when enabled in the PSR-12 ruleset:

    <!-- Code MUST use an indent of 4 spaces for each indent level, and MUST NOT use tabs for indenting. -->
    <rule ref="Generic.WhiteSpace.ScopeIndent">
        <properties>
            <property name="ignoreIndentationTokens" type="array">
                <element value="T_COMMENT"/>
                <element value="T_DOC_COMMENT_OPEN_TAG"/>
            </property>
            <property name="exact" value="true" />
        </properties>
    </rule>

In the projects I have tested the main problem that is occurring right now is that chained method calls split over multiple lines are falsely detected. An example:

$foo->bar()
    ->baz(); // An indentation error is thrown on this line.

I propose to skip exact checking of multi-line chained method calls.

This puts us one step closer to a strict 4-space indentation rule for PSR-12, and it will allow to use sniffs suchs as PEAR.WhiteSpace.ObjectOperatorIndent without conflicts.

[jrfnl]

Please have a look at PR #2224 which is making changes for that type of code as well.

[pfrenssen]

Please have a look at PR #2224 which is making changes for that type of code as well.

Awesome 👍

That's indeed why I made this PR. It will make sure that any custom indenting like proposed in that PR will work together with Generic.WhiteSpace.ScopeIndent without causing conflicts.

[drupol]

I confirm that this is fixing the issue in our code. Thanks @pfrenssen !