This section explains the coding style policy for RSS-Bridge with examples and references to external resources. Please make sure your code is compliant before opening a pull request.

You will automatically be notified if issues were found in your pull request. You must fix those issues before the pull request will be merged. Refer to phpcs.xml for a complete list of policies enforced by Travis-CI.

If you want to run the checks locally, make sure you have phpcs and phpunit installed on your machine and run following commands in the root directory of RSS-Bridge (tested on Debian):

./vendor/bin/phpcs --standard=phpcs.xml --warning-severity=0 --extensions=php -p ./
./vendor/bin/phpunit

The following list provides an overview of all policies applied to RSS-Bridge.

Whitespace

Add a new line at the end of a file

Each PHP/CSS/HTML file must end with a new line at the end of a file.

Bad

{
    // code here
} // This is the end of the file

Good

{
    // code here
}
// This is the end of the file

Reference: PSR2.Files.EndFileNewline

Do not add a whitespace before a semicolon

A semicolon indicates the end of a line of code. Spaces before the semicolon is unnecessary and must be removed.

Bad

echo 'Hello World!' ;

Good

echo 'Hello World!';

Reference: Squiz.WhiteSpace.SemicolonSpacing

Do not add whitespace at start or end of a file or end of a line

Whitespace at the end of lines or at the start or end of a file is invisible to the reader and absolutely unnecessary. Thus it must be removed.

Reference: Squiz.WhiteSpace.SuperfluousWhitespace

Indentation

Use spaces indentation

Maximum Line Length

180

Strings

Whenever possible use single quote strings

PHP supports both single quote strings and double quote strings. For pure text you must use single quote strings for consistency. Double quote strings are only allowed for special characters (i.e. "\n") or inlined variables (i.e. "My name is {$name}");

Bad

echo "Hello World!";

Good

echo 'Hello World!';

Reference: Squiz.Strings.DoubleQuoteUsage

Add spaces around the concatenation operator

The concatenation operator should have one space on both sides in order to improve readability.

Bad

$text = $greeting.' '.$name.'!';

Good (add spaces)

$text = $greeting . ' ' . $name . '!';

You may break long lines into multiple lines using the concatenation operator. That way readability can improve considerable when combining lots of variables.

Bad

$text = $greeting.' '.$name.'!';

Good (split into multiple lines)

$text = $greeting
. ' '
. $name
. '!';

Reference: Squiz.Strings.ConcatenationSpacing

Use a single string instead of concatenating

While concatenation is useful for combining variables with other variables or static text. It should not be used to combine two sets of static text. See also: Maximum line length

Bad

$text = 'This is' . 'a bad idea!';

Good

$text = 'This is a good idea!';

Reference: Generic.Strings.UnnecessaryStringConcat

Constants

Use UPPERCASE for constants

As in most languages, constants should be written in UPPERCASE.

Notice: This does not apply to keywords!

Bad

const pi = 3.14;

Good

const PI = 3.14;

Reference: Generic.NamingConventions.UpperCaseConstantName

Keywords

Use lowercase for true, false and null

true, false and null must be written in lower case letters.

Bad

if($condition === TRUE && $error === FALSE) {
    return NULL;
}

Good

if($condition === true && $error === false) {
    return null;
}

Reference: Generic.PHP.LowerCaseConstant

Operators

Operators must have a space around them

Operators must be readable and therefore should have spaces around them.

Bad

$text='Hello '.$name.'!';

Good

$text = 'Hello ' . $name . '!';

Reference: Squiz.WhiteSpace.OperatorSpacing

Functions

Parameters with default values must appear last in functions

It is considered good practice to make parameters with default values last in function declarations.

Bad

function showTitle($duration = 60000, $title) { ... }

Good

function showTitle($title, $duration = 60000) { ... }

Reference: PEAR.Functions.ValidDefaultValue

Calling functions

Function calls must follow a few rules in order to maintain readability throughout the project:

Do not add whitespace before the opening parenthesis

Bad

$result = my_function ($param);

Good

$result = my_function($param);

Do not add whitespace after the opening parenthesis

Bad

$result = my_function( $param);

Good

$result = my_function($param);

Do not add a space before the closing parenthesis

Bad

$result = my_function($param );

Good

$result = my_function($param);

Do not add a space before a comma

Bad

$result = my_function($param1 ,$param2);

Good

$result = my_function($param1, $param2);

Add a space after a comma

Bad

$result = my_function($param1,$param2);

Good

$result = my_function($param1, $param2);

Reference: Generic.Functions.FunctionCallArgumentSpacing

Do not add spaces after opening or before closing bracket

Parenthesis must tightly enclose parameters.

Bad

if( $condition ) { ... }

Good

if($condition) { ... }

Reference: PSR2.ControlStructures.ControlStructureSpacing

Structures

Structures must always be formatted as multi-line blocks

A structure should always be treated as if it contains a multi-line block.

Add a space after closing parenthesis

Bad

if($condition){
    ...
}

Good

if($condition) {
    ...
}

Add body into new line

Bad

if($condition){ ... }

Good

if($condition) {
    ...
}

Close body in new line

Bad

if($condition){
    ... }

Good

if($condition) {
    ...
}

Reference: Squiz.ControlStructures.ControlSignature

If-Statements

Use elseif instead of else if

For sake of consistency else if is considered bad practice.

Bad

if($conditionA) {

} else if($conditionB) {

}

Good

if($conditionA) {

} elseif($conditionB) {

}

Reference: PSR2.ControlStructures.ElseIfDeclaration

Do not write empty statements

Empty statements are considered bad practice and must be avoided.

Bad

if($condition) {
    // empty statement
} else {
    // do something here
}

Good (invert condition)

if(!$condition) {
    // do something
}

Reference: Generic.CodeAnalysis.EmptyStatement

Do not write unconditional if-statements

If-statements without conditions are considered bad practice and must be avoided.

if(true) {

}

Reference: Generic.CodeAnalysis.UnconditionalIfStatement

Classes

Use PascalCase for class names

Class names must be written in PascalCase.

Bad

class mySUPERclass { ... }

Good

class MySuperClass { ... }

Reference: PEAR.NamingConventions.ValidClassName

Do not use final statements inside final classes

Final classes cannot be extended, so it doesn't make sense to add the final keyword to class members.

Bad

final class MyClass {
    final public function MyFunction() {

    }
}

Good (remove the final keyword from class members)

final class MyClass {
    public function MyFunction() {

    }
}

Reference: Generic.CodeAnalysis.UnnecessaryFinalModifier

Do not override methods to call their parent

It doesn't make sense to override a method only to call their parent. When overriding methods, make sure to add some functionality to it.

Bad

class MyClass extends BaseClass {
    public function BaseFunction() {
        parent::BaseFunction();
    }
}

Good (don't override the function)

class MyClass extends BaseClass {

}

Reference: Generic.CodeAnalysis.UselessOverridingMethod

abstract and final declarations MUST precede the visibility declaration

When declaring abstract and final functions, the visibility (scope) must follow after abstract or final.

Bad

class MyClass extends BaseClass {
    public abstract function AbstractFunction() { }
    public final function FinalFunction() { }
}

Good (abstract and final before public)

class MyClass extends BaseClass {
    abstract public function AbstractFunction() { }
    final public function FinalFunction() { }
}

Reference: PSR2.Methods.MethodDeclaration

static declaration MUST come after the visibility declaration

The static keyword must come after the visibility (scope) parameter.

Bad

class MyClass extends BaseClass {
    static public function StaticFunction() { }
}

Good (static after public)

class MyClass extends BaseClass {
    public static function StaticFunction() { }
}

Reference: PSR2.Methods.MethodDeclaration

Casting

Do not add spaces when casting

The casting type should be put into parenthesis without spaces.

Bad

$text = ( string )$number;

Good

$text = (string)$number;

Reference: Squiz.WhiteSpace.CastSpacing

Arrays

Always use the short array syntax