Extend semicolon rule to multiline expressions

[ashamrov]

Extend semicolon rule to multiline expressions

Summary

Extends the semicolon-on-its-own-line rule from chained method calls to all multiline expressions (ternary, comparison, logical). Introduces RFC 2119 requirement level keywords throughout the style guide.

Changes

RFC 2119 keywords

• Added a reference to RFC 2119 in the style guide intro, defining the meaning of MUST, SHOULD, MAY, etc.
• Applied RFC 2119 keywords to rules in the "Splitting in several lines" section

Semicolon placement rule (extended)

• Renamed "Chained method calls" section to "Semicolon placement in multiline expressions"
• The general rule: the closing semicolon MUST be placed on its own line when a statement spans multiple lines
• Added sub-sections with examples for:
  • Chained method calls (existing rule, preserved as-is)
  • Ternary expressions (new — single-line vs multiline examples; multiline form puts return on its own line with the condition indented below)
  • Multiline comparison and logical expressions (new — single-line vs multiline examples)
• Updated getPrice() example in the Money/Doctrine section to match the new ternary style

Cross-references

• Added "See also" link in "Splitting in several lines" → semicolon placement section
• Added "See also" link in "Multiline comparison and logical expressions" → "Splitting in several lines"
• Updated table of contents to reflect the renamed section

Test plan

• Verify all internal anchor links in the README resolve correctly
• Confirm code examples render properly on GitHub
• Review that RFC 2119 keywords are used consistently

[plamen-dragiyski-work-psr]

if a condition is split into separate lines, every part MUST be on its own line (including first — on the new line, and last — new line after). All parts MUST be indented;

If this is true, shouldn't

<?php
// single line – no special rule
$isValid = $a && $b || $c;

// multiline – semicolon on its own line
$isValid = $conditionA
    && $conditionB
    && $conditionC
;

be something like

<?php
// single line – no special rule
$isValid = $a && $b || $c;

// multiline – semicolon on its own line
$isValid =
    $conditionA
    && $conditionB
    && $conditionC
;

[yuri-gaidoba-paysera]

if a condition is split into separate lines, every part MUST be on its own line (including first — on the new line, and last — new line after). All parts MUST be indented;

If this is true, shouldn't

<?php
// single line – no special rule
$isValid = $a && $b || $c;

// multiline – semicolon on its own line
$isValid = $conditionA
    && $conditionB
    && $conditionC
;

be something like

<?php
// single line – no special rule
$isValid = $a && $b || $c;

// multiline – semicolon on its own line
$isValid =
    $conditionA
    && $conditionB
    && $conditionC
;

Why?

I think we should apply this rule only where it provides a clear, practical benefit. The main value of moving the semicolon to a separate line is reducing diff noise when code is extended incrementally (e.g., chained calls or long logical expressions).

If putting the semicolon on a separate line does not improve diff stability or maintainability, then it doesn’t really justify the added visual inconsistency.

So for me the rule is:

• use it where it meaningfully reduces future diffs (chained calls, possibly long logical expressions)
• avoid it where it brings no tangible benefit (ternary operators, simple expressions, after closing parenthesis)

This keeps the style intentional rather than mechanically consistent.

[yuri-gaidoba-paysera]

// multiline – semicolon on its own line
$isValid =
$conditionA
&& $conditionB
&& $conditionC
;

Breaking after = does not provide the same benefit as breaking chained calls. It doesn’t meaningfully reduce diff noise, but it does make the code harder to scan.