We've had PSR-12 as an option for a few years now and we still allow the 'old' way of doing things with regards a number of areas. For me the most common one, is line wrapping.

I would like to propose that we formally deprecate the MCS variants of wrapping in favour of the PSR-12 variants:

Voting

Vote A

One way of doing things. Deprecate the Moodle Coding Style variants

Vote B

Keep the status quo

Explanation

MCS: https://moodledev.io/general/development/policies/codingstyle#maximum-line-length

We currently allow things like the following:

Class declarations

The opening brace is on the same line as the last implented interface:

class provider implements

        // These lines are indented with 8 spaces to distinguish them visually from the class body.

        \core_privacy\local\metadata\provider,

        \core_privacy\local\request\subsystem\provider,

        \core_privacy\local\request\core_userlist_provider {

    // Class body indented with 4 spaces.

}

Function sigs

The opening brace is on the same line as the last parameter:
Multiple parameters per line spread over mulitple lines.

protected function component_class_callback_failed(\Throwable $e, string $component, string $interface,

        string $methodname, array $params) {

    global $CFG, $DB;

    if ($this->observer) {

        // ...

    }

}

Function calls

Multiple params spread over multiple lines.

do_something($param1, $param2, null, null,

    $param5, null, true);

Arrays

Multiple params spread over multiple lines.

$plugininfo['preferences'][$plugin] = ['id' => $plugin, 'link' => $pref_url,

    'string' => $modulenamestr];

Proposal

we should deprecte the MCS variants in favour of pure PSR-12 (PER-2.0)

Class declarations

https://www.php-fig.org/per/coding-style/#41-extends-and-implements

class ClassName extends ParentClass implements

    \ArrayAccess,

    \Countable,

    \Serializable

{

Function sigs

https://www.php-fig.org/per/coding-style/#45-method-and-function-parameters

In the argument list, there MUST NOT be a space before each comma, and there MUST be one space after each comma.

Method and function parameters with default values MUST go at the end of the argument list.

Argument lists MAY be split across multiple lines, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the next line, and there MUST be only one argument per line.

When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them.

When you have a return type declaration present, there MUST be one space after the colon followed by the type declaration. The colon and declaration MUST be on the same line as the argument list closing parenthesis with no spaces between the two characters.

    public function aVeryLongMethodName(

        ClassTypeHint $arg1,

        &$arg2,

        array $arg3 = [],

    ) {

    }

    public function anotherFunction(

        string $foo,

        string $bar,

        int $baz,

    ): string {

    }

Note: Trailing commas are required in PER-2.0 and valid for all code from Moodle 4.2 onwards. Moodle 4.1 still allows PHP 7.4 which does not support them.

Function calls

https://www.php-fig.org/per/coding-style/#47-method-and-function-calls

When making a method or function call, there MUST NOT be a space between the method or function name and the opening parenthesis, there MUST NOT be a space after the opening parenthesis, and there MUST NOT be a space before the closing parenthesis. In the argument list, there MUST NOT be a space before each comma, and there MUST be one space after each comma.

Argument lists MAY be split across multiple lines, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the next line, and there MUST be only one argument per line. A single argument being split across multiple lines (as might be the case with a closure or array) does not constitute splitting the argument list itself.

If using named arguments, there MUST NOT be a space between the argument name and colon, and there MUST be a single space between the colon and the argument value. For example:

$foo->bar(

    $longArgument,

    $longerArgument,

    $muchLongerArgument,

);

somefunction($foo, $bar, [

  // ...

], $baz);

$app->get('/hello/{name}', function ($name) use ($app) {

    return 'Hello ' . $app->escape($name);

});

Arrays

https://www.php-fig.org/per/coding-style/#11-arrays

Array declarations MAY be split across multiple lines, where each subsequent line is indented once. When doing so, the first value in the array MUST be on the next line, and there MUST be only one value per line.

When the array declaration is split across multiple lines, the opening bracket MUST be placed on the same line as the equals sign. The closing bracket MUST be placed on the next line after the last value. There MUST NOT be more than one value assignment per line. Value assignments MAY use a single line or multiple lines.

$arr1 = ['single', 'line', 'declaration'];

$arr2 = [

    'multi',

    'line',

    'declaration',

    ['values' => 1, 5, 7],

    [

        'nested',

        'array',

    ],

];

Rationale

At the moment we have two, or even three, ways of doing things. When this is the case it is very hard to get consistent code, and even harder to make our automated tooling work for us

If we can standardise on more of our coding style, then the use of tooling such as Rector becomes more achievable.

Notes

As with any coding style change issue we will not blanket change all file.

We will only change files that are touched for other reasons, or if a developer wants to change a file they are working on.