RSS-Bridge Search Search...

GitHub Repository
Help/Support/Bugs
Docker Images

Show Code Blocks

Dark Mode

Powered by Daux.io

# For Developers
Coding style policy

April 14, 2023 at 12:32 PM Edit on GitHub

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.

Example

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.

Example

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

There is no maximum line length.

# #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}"`);

Example

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.

Example

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.

Example

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

Example

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!

Example

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.

Example

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.

Example

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.

Example

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

Example

Bad

    $result = my_function ($param);

Good

    $result = my_function($param);

Do not add whitespace after the opening parenthesis

Example

Bad

    $result = my_function( $param);

Good

    $result = my_function($param);

Do not add a space before the closing parenthesis

Example

Bad

    $result = my_function($param );

Good

    $result = my_function($param);

Do not add a space before a comma

Example

Bad

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

Good

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

Add a space after a comma

Example

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.

Example

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

Example

Bad

    if($condition){
        ...
    }

Good

    if($condition) {
        ...
    }

Add body into new line

Example

Bad

    if($condition){ ... }

Good

    if($condition) {
        ...
    }

Close body in new line

Example

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.

Example

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.

Example

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.

Example

    if(true) {

    }

Reference: `Generic.CodeAnalysis.UnconditionalIfStatement`

# #Classes

## #Use PascalCase for class names

Class names must be written in PascalCase.

Example

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.

Example

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.

Example

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`.

Example

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.

Example

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.

Example

Bad

    $text = ( string )$number;

Good

    $text = (string)$number;

Reference: `Squiz.WhiteSpace.CastSpacing`

# #Arrays

## #Always use the short array syntax