Minimum Version: 7.2

For PHP, we use a foundation of PSR-1 and PSR-12, with some slight modifications on code structure and naming conventions. These customizations are shown below.

Linting Code

We use a custom standard for the phpcs tool, available at Submitty/submitty-php-codesniffer. To set up the tool to use it, all you need to do is run composer install from within the site/ directory, which handles installing the dependencies and setting up the phpcs install paths. To run phpcs, you can use the following command:

php vendor/bin/phpcs --standard=tests/ruleset.xml [path/to/file/or/directory]

where if you leave off the path, it will analyze all files and directories for Submitty. Additionally, you can apply the automatic fixer to your code by running:

php vendor/bin/phpcbf --standard=tests/ruleset.xml [path/to/file/or/directory]

Classes, Methods

class Test {
    public function foo() {
        // code
    }

    public function method(
        $long_arg_name_1,
        $another_long_name,
        $third_long_name
    ) {
        // code
    }
}

Control Structures

if ($foo) {
    // code
}
elseif ($bar) {
    // code
}
else {
    // code
}
do {
    // code
} while ($foo);

Naming Conventions

Type Declarations

Wherever possible, you should use type declarations in your code. This helps our static analysis tool function more accurately, and alleviate a class of bugs from entering our codebase. Whenever possible, you should declare the type inline with the code:

function foo(string $bar, ?int $baz): string;

In some cases, such as for arrays of a type or mixed values, this is not possible. In these cases, you should write the type out in the docstring using phpDocumentator conventions. However, if possible, still attempt to put a type (such as array) inline in the code. An example using array of one type of object and union types:

/**
 * @param string[] $bar
 * @param A|B $baz
 */
function foo(array $bar, $baz): void;