coding-standards.xml

<?xml version="1.0"?>

<!-- in command line, use -s to find out what rule was applied for each error -->

<ruleset name="zebra">

    <description>Coding standards</description>

    <file>Zebra_Database.php</file>

    <!-- the test suite is held to the same standard as the library, since ten thousand lines of it that
         nothing checks drift into whatever each file felt like at the time -->
    <file>tests</file>

    <!-- everything under here is either written by the tests as they run or is not ours to begin with -->
    <exclude-pattern>tests/tmp/*</exclude-pattern>
    <exclude-pattern>tests/coverage-html/*</exclude-pattern>

    <ini name="memory_limit" value="64M"/>
    <arg name="report-width" value="130"/>

    <rule ref="PSR12">

        <!-- Let the Git manage the EOL cross the platforms. -->
        <exclude name="Generic.Files.LineEndings.InvalidEOLChar"/>

        <!-- Don't warn about lines being too long -->
        <exclude name="Generic.Files.LineLength.TooLong"/>

        <!-- Allow class names to be written in snake_case -->
        <exclude name="Squiz.Classes.ValidClassName.NotCamelCaps"/>

        <!-- The class is not in a namespace, which is deliberate for now - putting it in one would break every existing
             installation, so it is something for a future major version. Until then this is the only violation reported,
             and leaving it reported means a permanently failing check that everyone learns to ignore. -->
        <exclude name="PSR1.Classes.ClassDeclaration.MissingNamespace"/>

        <!-- Don't force braces being on the same line as the function's declaration -->
        <exclude name="PSR2.Classes.ClassDeclaration.OpenBraceNewLine" />
        <exclude name="Squiz.Classes.ClassDeclaration.OpenBraceNewLine" />
        <exclude name="PEAR.Functions.FunctionDeclaration.BraceOnSameLine" />
        <exclude name="Squiz.Functions.MultiLineFunctionDeclaration.BraceOnSameLine" />

        <!-- Allow method names to be written in snake_case -->
        <exclude name="PSR1.Methods.CamelCapsMethodName.NotCamelCaps" />

        <!-- Allow blank line before the closing brace of a class -->
        <exclude name="PSR2.Classes.ClassDeclaration.CloseBraceAfterBody" />

        <!-- Allow blank line after the CASE and DEFAULT keywords -->
        <exclude name="PSR2.ControlStructures.SwitchDeclaration.BodyOnNextLineCASE" />
        <exclude name="PSR2.ControlStructures.SwitchDeclaration.BodyOnNextLineDEFAULT" />

        <!-- I write queries as multiline but the first thing after the opening  parenthesis is the opening quote -->
        <exclude name="PSR2.Methods.FunctionCallSignature.ContentAfterOpenBracket" />

        <!-- Allow blank line before the closing brace of a function -->
        <exclude name="PSR2.Methods.FunctionClosingBrace.SpacingBeforeClose" />

        <!-- Allow private methods to have underscore as their name's first character -->
        <exclude name="PSR2.Methods.MethodDeclaration.Underscore" />

        <!-- Allow blank line after the opening brace of a class -->
        <exclude name="PSR12.Classes.OpeningBraceSpace.Found" />

        <!-- In multi-line control structures, the first expression can be on the next line -->
        <exclude name="PSR12.ControlStructures.ControlStructureSpacing.FirstExpressionLine" />

        <!-- In multi-line control structures, the parenthesis after the last expression can be on the next line -->
        <exclude name="PSR12.ControlStructures.ControlStructureSpacing.CloseParenthesisLine" />

        <!-- Allow blank lines at the start/end of control structures -->
        <exclude name="Squiz.WhiteSpace.ControlStructureSpacing.SpacingAfterOpen" />
        <exclude name="Squiz.WhiteSpace.ControlStructureSpacing.SpacingBeforeClose" />

        <!-- Single statement bodies are written without braces throughout this library - "if (!$this->_connected())
             return false;" and some 165 more like it. That is the house style rather than an accident, and rewriting
             all of them would churn most of the file without making any of it clearer. -->
        <exclude name="Generic.ControlStructures.InlineControlStructure"/>

        <!-- Replaced by the rule below, which says the same thing for named declarations and the opposite
             for closures. PSR-12 wants a space in both cases and the sniff has no property to separate
             them, so the check is re-stated rather than switched off. Both codes are named because the
             Squiz sniff extends the PEAR one and reports single and multi line declarations separately. -->
        <exclude name="PEAR.Functions.FunctionDeclaration.SpaceAfterFunction" />
        <exclude name="Squiz.Functions.MultiLineFunctionDeclaration.SpaceAfterFunction" />

        <!-- A closure short enough to sit on one line is written on one line - "function($value) { return
             $value; }". These two sniffs check the braces of closures and named declarations alike and
             have no property to separate them, but the Kernighan/Ritchie rule further down does the same
             check for named declarations only: its checkClosures property is off by default, which is
             exactly the distinction wanted here. So these two go and that one stays, and a named
             declaration written on one line is still reported. -->
        <exclude name="Squiz.Functions.MultiLineFunctionDeclaration.ContentAfterBrace" />
        <exclude name="Squiz.WhiteSpace.ScopeClosingBrace.ContentBefore" />

        <!-- Replaced by the rule below, which makes the same exception for closures. The statement inside
             a one line closure is what this counts as the second statement on the line. -->
        <exclude name="Generic.Formatting.DisallowMultipleStatements" />

    </rule>

    <!-- One space after the "function" keyword when a name follows it, none when it does not - so
    "function get_tables($database)" and "function($value) { ... }" are both correct. -->
    <rule ref="tests/standards/Zebra/Sniffs/Functions/FunctionKeywordSpacingSniff.php" />

    <!-- Each statement on a line by itself, except inside a closure - so "array_map(function($row) { return
    $row['id']; }, $rows)" is fine while "$a = 1; $b = 2;" is still reported. -->
    <rule ref="tests/standards/Zebra/Sniffs/Formatting/ClosureAwareMultipleStatementsSniff.php" />

    <!-- Function declarations follow the "Kernighan/Ritchie style". The function brace is on the same line as the
    function declaration. One space is required between the closing parenthesis and the brace. -->
    <rule ref="Generic.Functions.OpeningFunctionBraceKernighanRitchie" />

    <!-- Every test file declares a class and includes the bootstrap beside it, which is what this sniff calls a side
    effect. That is how a PHPUnit suite is put together - the alternative is an autoloader that exists only so that a
    check can be satisfied - so the rule is switched off for the tests rather than left reported and ignored. -->
    <rule ref="PSR1.Files.SideEffects">
        <exclude-pattern>tests/*</exclude-pattern>
    </rule>

</ruleset>