Generic/ArrayIndent: add XML documentation

[rodrigoprimo]

Description

This PR adds the XML documentation for the Generic.Arrays.ArrayIndent sniff.

I left some inline comments below highlighting decisions I made while creating this documentation that I'm not sure about.

Suggested changelog entry

Add XML documentation for the Generic.Arrays.ArrayIndent sniff.

Related issues/external references

Part of #148

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
  • This change is only breaking for integrators, not for external standards or end-users.
• Documentation improvement

PR checklist

• I have checked there is no other PR open for the same change.
• I have read the Contribution Guidelines.
• I grant the project the right to include and distribute the code under the BSD-3-Clause license (and I have the right to grant these rights).
• I have added tests to cover my changes.
• I have verified that the code complies with the projects coding standards.
• [Required for new sniffs] I have added XML documentation for the sniff.

[rodrigoprimo]

I opted to use opening square bracket/parenthesis here and in a few other places as the sniff supports both array syntaxes. That is not super correct as in the old syntax, the opening token of an array is not just a parenthesis, but actually array(.

[jrfnl]

What about using the phrase "open brace" (and "close brace" for the end, of course) ? Would that work ? What do you think ?

[rodrigoprimo]

For this <standard> block, I'm specifically mentioning multi-line arrays. It is the only error that could apply to a single-line array, but single-line arrays are not handled by this sniff. The example that I have in mind is:

    $a = 
[1, 2];

[jrfnl]

Just tested, that snippet would not trigger the sniff anyway, so we can forget about it.

[jrfnl]

@rodrigoprimo Sorry for my tardiness with this review.

Generally speaking the documentation is good, there is just some phrasing which could be misinterpreted/interpreted in different ways, which may be confusing . Let's have another look at how to make it as clear as possible.

I think with some small tweaks this can probably be finished quickly. Again, my apologies for the delay in the review.

[jrfnl]

As a possible alternative (to get away from the kind of braces):

Suggested change

	The opening square bracket/parenthesis of a multi-line array must be indented at least to the same level of the start of the statement.
	The start of a multi-line array must be indented at least to the same level as the start of the statement.

[jrfnl]

Suggested change

	<code title="Valid: Opening square bracket/parenthesis token of a multi-line array indented at least to the same level of the start of the statement.">
	<code title="Valid: Opening square bracket/parenthesis token of a multi-line array indented at least to the same level as the start of the statement.">

(aside from having a think about the braces phrasing)

[jrfnl]

Suggested change

	<code title="Invalid: Opening square bracket/parenthesis of a multi-line array not indented at least to the same level of the start of the statement.">
	<code title="Invalid: Opening square bracket/parenthesis of a multi-line array not indented at least to the same level as the start of the statement.">

(aside from having a think about the braces phrasing)

[jrfnl]

Just tested, that snippet would not trigger the sniff anyway, so we can forget about it.

[jrfnl]

What about adding a second code sample here showing that having the opening brace on the same line as the assignment is also perfectly valid under this rule ?

[jrfnl]

Okay, not sure how to rephrase this, but there are some things here which don't ring true/could be confusing:

• The indentation is only checked for the first line of each element (subsequent lines are not checked for indentation).
• "Four spaces beyond"- not sure how much margin that give to interpret this as "at least four spaces", while the rule is "exactly four spaces".
• "the indentation level of the opening square bracket/parenthesis" - it's not about the indentation/position of the brackets, but about the start of statement which includes the array opener.

Let's rethink the phrasing of this rule.

Note: this also means the Valid/Invalid phrasing may need updating.

[jrfnl]

Would this be clearer if the indentation was phrased to be related to "same level of indentation as the start of the statement containing the array opener" (or something along those lines) ?