-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Customisable Sniff Properties
The behaviour of some sniffs can be changed by setting certain sniff properties in your ruleset.xml file. This page lists the sniff properties that are available for customisation. For properties that were added after ruleset support was introduced in version 1.3.0, the first stable version that made the property available is listed.
For more information about changing sniff behaviour by customising your ruleset, see the Annotated ruleset.
- Generic Sniffs
- Generic.Arrays.ArrayIndent
- Generic.CodeAnalysis.UnusedFunctionParameter
- Generic.ControlStructures.InlineControlStructure
- Generic.Debug.ClosureLinter
- Generic.Debug.ESLint
- Generic.Files.LineEndings
- Generic.Files.LineLength
- Generic.Formatting.MultipleStatementAlignment
- Generic.Formatting.SpaceAfterCast
- Generic.Formatting.SpaceAfterNot
- Generic.Functions.OpeningFunctionBraceBsdAllman
- Generic.Functions.OpeningFunctionBraceKernighanRitchie
- Generic.Metrics.CyclomaticComplexity
- Generic.Metrics.NestingLevel
- Generic.NamingConventions.CamelCapsFunctionName
- Generic.PHP.ForbiddenFunctions
- Generic.PHP.NoSilencedErrors
- Generic.Strings.UnnecessaryStringConcat
- Generic.WhiteSpace.ArbitraryParenthesesSpacing
- Generic.WhiteSpace.ScopeIndent
- Generic.WhiteSpace.SpreadOperatorSpacingAfter
- PEAR Sniffs
- PEAR.Commenting.FunctionComment
- PEAR.ControlStructures.ControlSignature
- PEAR.ControlStructures.MultiLineCondition
- PEAR.Formatting.MultiLineAssignment
- PEAR.Functions.FunctionCallSignature
- PEAR.Functions.FunctionDeclaration
- PEAR.WhiteSpace.ObjectOperatorIndent
- PEAR.WhiteSpace.ScopeClosingBrace
- PEAR.WhiteSpace.ScopeIndent
- PSR2 Sniffs
- PSR12 Sniffs
- Squiz Sniffs
- Squiz.Classes.ClassDeclaration
- Squiz.Commenting.FunctionComment
- Squiz.Commenting.LongConditionClosingComment
- Squiz.ControlStructures.ControlSignature
- Squiz.ControlStructures.ForEachLoopDeclaration
- Squiz.ControlStructures.ForLoopDeclaration
- Squiz.ControlStructures.SwitchDeclaration
- Squiz.CSS.ForbiddenStyles
- Squiz.CSS.Indentation
- Squiz.Functions.FunctionDeclaration
- Squiz.Functions.FunctionDeclarationArgumentSpacing
- Squiz.PHP.CommentedOutCode
- Squiz.PHP.DiscouragedFunctions
- Squiz.PHP.ForbiddenFunctions
- Squiz.Strings.ConcatenationSpacing
- Squiz.WhiteSpace.FunctionSpacing
- Squiz.WhiteSpace.MemberVarSpacing
- Squiz.WhiteSpace.ObjectOperatorSpacing
- Squiz.WhiteSpace.OperatorSpacing
- Squiz.WhiteSpace.SuperfluousWhitespace
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 3.2.0 |
One of the rules that this sniff enforces is the indent of keys in a multi-line array declaration. By default, this sniff ensures that each key is indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="Generic.Arrays.ArrayIndent">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
ignoreTypeHints | array | [] | 3.6.0 |
This sniff ensures that parameters passed to a function are used within that function, and warns if they are not. Sometimes, parameters can be left unused when doing something like implementing an interface, such as with the following code:
public function execute(InputInterface $input, OutputInterface $output): int
{
$output->writeln('Hello World!');
}
If the InputInterface
parameter does not need to be used, you can tell the sniff to ignore all variables with that type hint by setting the ignoreTypeHints
property.
<rule ref="Generic.CodeAnalysis.UnusedFunctionParameter">
<properties>
<property name="ignoreTypeHints" type="array">
<element value="InputInterface"/>
</property>
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
error | bool | true | - |
If the error
property is set to false
, a warning will be thrown for violations instead of an error.
<rule ref="Generic.ControlStructures.InlineControlStructure">
<properties>
<property name="error" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
errorCodes | array | [] | - |
ignoreCodes | array | [] | - |
The Generic.Debug.ClosureLinter
sniff runs the Google Closure Linter tool over JavaScript files and reports errors that the tool finds. All found errors are reported as PHP_CodeSniffer warnings by default.
There are two configurable options:
-
errorCodes
: a list of error codes that should show as errors instead of warnings -
ignoreCodes
: a list of error codes that should be ignored
Note: The error codes accepted by this sniff are the 4-digit codes generated by the
gjslint
tool and displayed in the warning messages produced by this sniff.
<rule ref="Generic.Debug.ClosureLinter">
<properties>
<property name="errorCodes" type="array">
<element value="0210"/>
</property>
<property name="ignoreCodes" type="array">
<element value="0001"/>
<element value="0110"/>
<element value="0240"/>
</property>
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
configFile | string | - | 2.9.0 |
The Generic.Debug.ESLint
sniff runs the ESLint tool over JavaScript files and reports errors that the tool finds. All found violations are reported as either PHP_CodeSniffer errors or warnings based on the severity level that the ESLint tool provides.
The sniff will attempt to auto-discover an ESLint config file in the current directory, but a config file path can also be specified by setting the configFile
property.
<rule ref="Generic.Debug.ESLint">
<properties>
<property name="configFile" value="/path/to/.eslintrc.json"/>
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
eolChar | string | \n | - |
This sniff ensures that files use a specific line ending, which can be customised by setting the eolChar
property.
<rule ref="Generic.Files.LineEndings">
<properties>
<property name="eolChar" value="\r\n" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
lineLimit | int | 80 | - |
absoluteLineLimit | int | 100 | - |
ignoreComments | bool | false | 3.1.0 |
This sniff checks all lines in a file and generates warnings if they are over lineLimit
characters in length and errors if they are over absoluteLineLimit
in length. These properties can be used to set the threshold at which errors are reported.
Note: The value of the
lineLimit
property should be less than or equal to the value of theabsoluteLineLimit
property.
<!--
Warn about lines longer than 100 chars,
and error for lines longer than 135 chars.
-->
<rule ref="Generic.Files.LineLength">
<properties>
<property name="lineLimit" value="100" />
<property name="absoluteLineLimit" value="135" />
</properties>
</rule>
If errors are not required, the value of absoluteLineLimit
can be set to zero.
<!-- Warn about lines longer than 135 chars, and never error. -->
<rule ref="Generic.Files.LineLength">
<properties>
<property name="lineLimit" value="135" />
<property name="absoluteLineLimit" value="0" />
</properties>
</rule>
If the ignoreComments
property is set to true
, comments at the end of a line will be ignored when calculating line lengths. This also ensures that no error or warning will be thrown for a line that only contains a comment, no matter how long the line is.
<rule ref="Generic.Files.LineLength">
<properties>
<property name="ignoreComments" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since | Removed In |
---|---|---|---|---|
alignAtEnd | bool | true | 3.6.0 | |
error | bool | false | - | 4.0.0 |
maxPadding | int | 1000 | - |
This sniff checks the alignment of assignment operators. If there are multiple adjacent assignments, it checks that the assignment operators of each assignment are aligned. By default, the sniff enforces that the end of the assignment operators are aligned, ensuring that the assigned values are aligned. This formats code like this:
$foo = 'foo';
$foo .= 'bar';
If you prefer the start of the assignment tokens to be aligned, you can set the alignAtEnd
sniff property to false
.
<rule ref="Generic.Formatting.MultipleStatementAlignment">
<properties>
<property name="alignAtEnd" value="false" />
</properties>
</rule>
Code will now be formatted like this:
$foo = 'foo';
$foo .= 'bar';
The difference in alignment between two adjacent assignments is occasionally quite large, so aligning assignment operators would create extremely long lines. By setting the maxPadding
property, you can configure the maximum amount of padding required to align the assignment with the surrounding assignments before the alignment is ignored and no warnings will be generated.
<rule ref="Generic.Formatting.MultipleStatementAlignment">
<properties>
<property name="maxPadding" value="50" />
</properties>
</rule>
If the error
property is set to true
, an error will be thrown for violations instead of a warning.
<rule ref="Generic.Formatting.MultipleStatementAlignment">
<properties>
<property name="error" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
spacing | int | 1 | 3.4.0 |
ignoreNewlines | bool | false | 3.4.0 |
This sniff checks the spacing after a type cast. By default, the sniff ensures there is one space after the cast, as shown in the following code snippet:
$var = (int) $foo;
Another common way of type casting is to follow the cast with no space, as shown in the following code snippet:
$var = (int)$foo;
If you prefer to write your code like this, you can set the spacing
property to 0
, or whatever padding you prefer.
<rule ref="Generic.Formatting.SpaceAfterCast">
<properties>
<property name="spacing" value="0" />
</properties>
</rule>
Sometimes complex statements are broken over multiple lines for readability. By default, this sniff will generate an error if the type cast is followed by a newline. Setting the ignoreNewlines
property to true
will allow newline characters after a type cast.
<rule ref="Generic.Formatting.SpaceAfterCast">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
spacing | int | 1 | 3.4.0 |
ignoreNewlines | bool | false | 3.4.0 |
This sniff checks the spacing after a !
operator. By default, the sniff ensures there is one space after the operator, as shown in the following code snippet:
if (! $foo) {
}
Another common way of using the !
operator is to follow it with no space, as shown in the following code snippet:
if (!$foo) {
}
If you prefer to write your code like this, you can set the spacing
property to 0
, or whatever padding you prefer.
<rule ref="Generic.Formatting.SpaceAfterNot">
<properties>
<property name="spacing" value="0" />
</properties>
</rule>
Sometimes complex statements are broken over multiple lines for readability, as shown in the following code snippet:
if (!
($foo || $bar)
) {
}
By default, this sniff will generate an error if the !
operator is followed by a newline. Setting the ignoreNewlines
property to true
will allow newline characters after a !
operator.
<rule ref="Generic.Formatting.SpaceAfterNot">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
checkFunctions | bool | true | 2.3.0 |
checkClosures | bool | false | 2.3.0 |
The sniff checks the position of the opening brace of a function and/or closure (anonymous function). The sniff only checks functions by default, but the checkFunctions
and checkClosures
properties can be used to have the sniff check one or both of these code blocks.
<!-- Don't check function braces, but check closure braces. -->
<rule ref="Generic.Functions.OpeningFunctionBraceBsdAllman">
<properties>
<property name="checkFunctions" value="false" />
<property name="checkClosures" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
checkFunctions | bool | true | 2.3.0 |
checkClosures | bool | false | 2.3.0 |
The sniff checks the position of the opening brace of a function and/or closure (anonymous function). The sniff only checks functions by default, but the checkFunctions
and checkClosures
properties can be used to have the sniff check one or both of these code blocks.
<!-- Don't check function braces, but check closure braces. -->
<rule ref="Generic.Functions.OpeningFunctionBraceKernighanRitchie">
<properties>
<property name="checkFunctions" value="false" />
<property name="checkClosures" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
complexity | int | 10 | - |
absoluteComplexity | int | 20 | - |
This sniff checks the cyclomatic complexity for functions by counting the different paths the function includes.
There are two configurable options:
-
complexity
: the cyclomatic complexity above which this sniff will generate warnings -
absoluteComplexity
: the cyclomatic complexity above which this sniff will generate errors
Note: The value of the
complexity
property should be less than or equal to the value of theabsoluteComplexity
property.
<rule ref="Generic.Metrics.CyclomaticComplexity">
<properties>
<property name="complexity" value="15" />
<property name="absoluteComplexity" value="30" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
nestingLevel | int | 5 | - |
absoluteNestingLevel | int | 10 | - |
This sniff checks how many level deep that code is nested within a function.
There are two configurable options:
-
nestingLevel
: the nesting level above which this sniff will generate warnings -
absoluteNestingLevel
: the nesting level above which this sniff will generate errors
<rule ref="Generic.Metrics.NestingLevel">
<properties>
<property name="nestingLevel" value="8" />
<property name="absoluteNestingLevel" value="12" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
strict | bool | true | 1.3.5 |
This sniff ensures function and method names are in CamelCaps.
Strictly speaking, a name cannot have two capital letters next to each other in CamelCaps format. By setting the strict
property to false
, the sniff applies the rule more leniently and allows for two capital letters next to each other in function and method names.
<rule ref="Generic.NamingConventions.CamelCapsFunctionName">
<properties>
<property name="strict" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
forbiddenFunctions | array | [sizeof=>count,delete=>unset] | 2.0.0 |
error | bool | true | - |
This sniff discourages the use of alias functions that are kept in PHP for compatibility with older versions. The sniff can be used to forbid the use of any function by setting the forbiddenFunctions
property. The property is defined as an array, with the keys being the names of the functions to forbid and the values being the names of suggested alternative functions to use instead. If no alternative function exists (i.e., the function should never be used) specify null
as the value.
<rule ref="Generic.PHP.ForbiddenFunctions">
<properties>
<property name="forbiddenFunctions" type="array">
<element key="print" value="echo"/>
<element key="create_function" value="null"/>
</property>
</properties>
</rule>
If the error
property is set to false
, a warning will be thrown for violations instead of an error.
<rule ref="Generic.PHP.ForbiddenFunctions">
<properties>
<property name="error" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
error | bool | true | - |
If the error
property is set to false
, a warning will be thrown for violations instead of an error.
<rule ref="Generic.PHP.NoSilencedErrors">
<properties>
<property name="error" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since | Removed In |
---|---|---|---|---|
allowMultiline | bool | false | 2.3.4 | |
error | bool | true | - | 4.0.0 |
This sniff checks that two strings using the same quoting style are not concatenated. Sometimes long strings are broken over multiple lines to work within a maximum line length, but this sniff will generate an error for these cases by default. Setting the allowMultiline
property to true
will get the sniff to allow string concatenation if the string covers multiple lines.
<rule ref="Generic.Strings.UnnecessaryStringConcat">
<properties>
<property name="allowMultiline" value="true" />
</properties>
</rule>
If the error
property is set to false
, a warning will be thrown for violations instead of an error.
<rule ref="Generic.Strings.UnnecessaryStringConcat">
<properties>
<property name="error" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
spacing | int | 0 | 3.3.0 |
ignoreNewlines | bool | false | 3.3.0 |
This sniff checks the padding inside parenthesis that are not being used by function declarations, function calls, or control structures. By default, the sniff ensures there are zero spaces inside the parenthesis, as shown in the following code snippet:
$foo = ($bar !== 'bar');
Another common way of padding parenthesis is to use a single space, as shown in the following code snippet:
$foo = ( $bar !== 'bar' );
If you prefer to write your code like this, you can set the spacing
property to 1
, or whatever padding you prefer.
<rule ref="Generic.WhiteSpace.ArbitraryParenthesesSpacing">
<properties>
<property name="spacing" value="1" />
</properties>
</rule>
Sometimes long statements are broken over multiple lines to work within a maximum line length, but this sniff will generate an error for these cases by default. Setting the ignoreNewlines
property to true
will allow newline characters inside parenthesis, and any required padding for alignment.
<rule ref="Generic.WhiteSpace.ArbitraryParenthesesSpacing">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | - |
exact | bool | false | - |
tabIndent | bool | false | 2.0.0 |
ignoreIndentationTokens | array | [] | 1.4.8 |
This sniff checks that code blocks are indented correctly. By default, this sniff ensures that code blocks are indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="Generic.WhiteSpace.ScopeIndent">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
The exact
property is used to determine whether an indent is treated as an exact number or as a minimum amount. By default, code blocks must be indented at least indent
spaces from the last code block. If exact
is set to true
, code blocks must be indented exactly indent
spaces from the last code block.
Note: Enforcing exact indent checking is generally not advised because it doesn't allow for any flexibility when indenting and aligning code. It is almost always better to use the default value and then allow other sniffs to enforce specific indenting rules.
<rule ref="Generic.WhiteSpace.ScopeIndent">
<properties>
<property name="exact" value="true" />
</properties>
</rule>
By default, this sniff enforces the use of spaces for indentation and also uses spaces when fixing the indentation of code blocks. If you prefer using tabs, you can set the tabIndent
property to true
.
Note: The size of each tab is important, so it should be specified using the
--tab-width
CLI argument or by adding<arg name="tab-width" value="4"/>
to your ruleset. This sniff will use this value when checking and fixing indents.
<!-- Tabs should represent 4 spaces. -->
<arg name="tab-width" value="4"/>
...
<!-- Indent using tabs. -->
<rule ref="Generic.WhiteSpace.ScopeIndent">
<properties>
<property name="tabIndent" value="true" />
</properties>
</rule>
Setting the ignoreIndentationTokens
property provides the sniff with a list of tokens that do not need to be checked for indentation. This is commonly used to ignore indentation for code structures such as comments and here/nowdocs.
<rule ref="Generic.WhiteSpace.ScopeIndent">
<properties>
<property name="ignoreIndentationTokens" type="array">
<element value="T_COMMENT"/>
<element value="T_DOC_COMMENT_OPEN_TAG"/>
</property>
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
spacing | int | 0 | 3.5.0 |
ignoreNewlines | bool | false | 3.5.0 |
This sniff checks the spacing after a ...
operator. By default, the sniff ensures there is no space after the operator, but you can enforce a fixed number of spaces by setting the spacing
property.
<rule ref="Generic.WhiteSpace.SpreadOperatorSpacingAfter">
<properties>
<property name="spacing" value="1" />
</properties>
</rule>
If you want to allow a newline after the operator, you can set the ignoreNewlines
property to true
.
<rule ref="Generic.WhiteSpace.SpreadOperatorSpacingAfter">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
minimumVisibility | string | private | 3.6.0 |
This sniff verifies that functions are documented using a docblock. By default, all functions are checked regardless of their visibility, but the sniff can be told to ignore private and protected functions using the minimumVisibility
property. When set to protected
, only public and protected functions will be checked. When set to public
, only public functions will be checked.
<rule ref="PEAR.Commenting.FunctionComment">
<properties>
<property name="minimumVisibility" value="public" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
ignoreComments | bool | true | 1.4.0 |
Note: The
ignoreComments
property is inherited from the AbstractPattern sniff.
This sniff verifies that control structures match a specific pattern of whitespace and bracket placement. By default, comments placed within the declaration will generate an error, but the sniff can be told to ignore comments by setting the ignoreComments
property to true
.
<rule ref="PEAR.ControlStructures.ControlSignature">
<properties>
<property name="ignoreComments" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.4.7 |
One of the rules that this sniff enforces is the indent of a condition that has been split over multiple lines. By default, this sniff ensures that each line of the condition is indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PEAR.ControlStructures.MultiLineCondition">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.4.7 |
One of the rules that this sniff enforces is the indent of an assignment that has been split over multiple lines. By default, this sniff ensures that the line with the assignment operator is indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PEAR.Formatting.MultiLineAssignment">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.3.4 |
allowMultipleArguments | bool | true | 1.3.6 |
requiredSpacesAfterOpen | int | 0 | 1.5.2 |
requiredSpacesBeforeClose | int | 0 | 1.5.2 |
One of the rules this sniff enforces is that function calls have the correct padding inside their bracketed argument lists. By default, the sniff ensures there are zero spaces following the opening bracket, and zero spaces preceding the closing bracket, as shown in the following code snippet:
$foo = getValue($a, $b, $c);
Another common way of padding function calls is to use a single space, as shown in the following code snippet:
$foo = getValue( $a, $b, $c );
If you prefer to write your code like this, you can set the requiredSpacesAfterOpen
and requiredSpacesBeforeClose
properties to 1
, or whatever padding you prefer.
<rule ref="PEAR.Functions.FunctionCallSignature">
<properties>
<property name="requiredSpacesAfterOpen" value="1" />
<property name="requiredSpacesBeforeClose" value="1" />
</properties>
</rule>
This sniff also enforces the formatting of multi-line function calls. By default, multiple arguments can appear on each line, as shown in the following code snippet:
$returnValue = foo(
$a, $b, $c,
$d, $e
);
Another common way of defining multi-line function calls is to have one argument per line, as shown in the following code snippet:
$returnValue = foo(
$a,
$b,
$c,
$d,
$e
);
If you prefer to write your code like this, you can set the allowMultipleArguments
property to false
.
<rule ref="PEAR.Functions.FunctionCallSignature">
<properties>
<property name="allowMultipleArguments" value="false" />
</properties>
</rule>
By default, this sniff ensures that each line in a multi-line function call is indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PEAR.Functions.FunctionCallSignature">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.4.7 |
One of the rules that this sniff enforces is the indent of each function argument in a multi-line function declaration. By default, this sniff ensures that each line is indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PEAR.Functions.FunctionDeclaration">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.4.6 |
multilevel | bool | false | 3.5.0 |
One of the rules that this sniff enforces is the indent of each line in a multi-line object chain. By default, this sniff ensures that each line is indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PEAR.WhiteSpace.ObjectOperatorIndent">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Another common way of indenting multi-line object chains is to increase and decrease the indent by one level at a time to show balanced method calls, as shown in the following code snippet:
$rootNode
->children()
->booleanNode('foo')
->defaultTrue()
->end()
->scalarNode('bar')
->defaultValue('default')
->end()
->end();
If you want to allow mutli-level indenting, set the multilevel
property to true
. This will allow each line to be indented 1 more or 1 less level than the previous line, while still ensuring that all lines are indented at least once.
<rule ref="PEAR.WhiteSpace.ObjectOperatorIndent">
<properties>
<property name="multilevel" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.3.4 |
One of the rules that this sniff enforces is the indent of the case terminating statement. By default, this sniff ensures that the statement is indented 4 spaces from the case
or default
keyword, but you can change the size of the indent by setting the indent
property.
<rule ref="PEAR.WhiteSpace.ScopeClosingBrace">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | - |
exact | bool | false | - |
tabIndent | bool | false | 2.0.0 |
ignoreIndentationTokens | array | [] | 1.4.8 |
Note: All properties are inherited from the Generic.WhiteSpace.ScopeIndent sniff.
See the Generic.WhiteSpace.ScopeIndent sniff for an explanation of all properties.
<!-- Tabs should represent 4 spaces. -->
<arg name="tab-width" value="4"/>
...
<rule ref="PEAR.WhiteSpace.ScopeIndent">
<properties>
<property name="exact" value="true" />
<property name="tabIndent" value="true" />
<property name="ignoreIndentationTokens" type="array">
<element value="T_COMMENT"/>
<element value="T_DOC_COMMENT_OPEN_TAG"/>
</property>
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.3.5 |
One of the rules that this sniff enforces is the indent of a list of implemented or extended class names that have been split over multiple lines. By default, this sniff ensures that the class names are indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PSR2.Classes.ClassDeclaration">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
requiredSpacesAfterOpen | int | 0 | 1.5.2 |
requiredSpacesBeforeClose | int | 0 | 1.5.2 |
This sniff checks that control structures have the correct padding inside their bracketed statement. By default, the sniff ensures there are zero spaces following the opening bracket, and zero spaces preceding the closing bracket, as shown in the following code snippet:
if ($condition === true) {
// Body.
}
Another common way of padding control structures is to use a single space, as shown in the following code snippet:
if ( $condition === true ) {
// Body.
}
If you prefer to write your code like this, you can set the requiredSpacesAfterOpen
and requiredSpacesBeforeClose
properties to 1
, or whatever padding you prefer.
<rule ref="PSR2.ControlStructures.ControlStructureSpacing">
<properties>
<property name="requiredSpacesAfterOpen" value="1" />
<property name="requiredSpacesBeforeClose" value="1" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.4.5 |
One of the rules that this sniff enforces is the indent of the case terminating statement. By default, this sniff ensures that the statement is indented 4 spaces from the case
or default
keyword, but you can change the size of the indent by setting the indent
property.
<rule ref="PSR2.ControlStructures.SwitchDeclaration">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.3.4 |
allowMultipleArguments | bool | false | 1.4.7 |
requiredSpacesAfterOpen | int | 0 | 1.5.2 |
requiredSpacesBeforeClose | int | 0 | 1.5.2 |
Note: All properties are inherited from the PEAR.Functions.FunctionCallSignature sniff, although the default value of
allowMultipleArguments
is changed.
See the PEAR.Functions.FunctionCallSignature sniff for an explanation of all properties.
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 3.5.0 |
Note: The
indent
property is inherited from the PSR2.Classes.ClassDeclaration sniff.
This sniff checks the indent of a list of implemented or extended class names that have been split over multiple lines, and the indent of variables passed to the constructor that have been split over multiple lines. By default, this sniff ensures that the class names and passed variables are indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PSR12.Classes.AnonClassDeclaration">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
allowOnly | bool | null | 3.5.4 |
This sniff ensures that boolean operators inside control structure conditions either all appear at the beginning of a line, or the end of a line, but not a mix of both. If you prefer to explicitly define where boolean operators should appear, you can set the allowOnly
property to either first
or last
to ensure that boolean operators are always the first or last content of a line.
<rule ref="PSR12.ControlStructures.BooleanOperatorPlacement">
<properties>
<property name="allowOnly" value="first" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 3.5.0 |
One of the rules that this sniff enforces is the indent of each condition in a control structure when the conditions have been split over multiple lines. By default, this sniff ensures that the conditions are indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="PSR12.ControlStructures.ControlStructureSpacing">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
maxDepth | int | 2 | 3.3.0 |
This sniff checks the depth of imported namespaces inside compound use statements. By default, this sniff ensures that the namespaces are no more than two levels deep, but you can change the depth limit by setting the maxDepth
property.
<rule ref="PSR12.Namespaces.CompoundNamespaceDepth">
<properties>
<property name="maxDepth" value="4" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
ignoreNewlines | bool | false | 3.3.0 |
ignoreSpacingBeforeAssignments | bool | true | 3.5.0 |
Note: All properties are inherited from the Squiz.WhiteSpace.OperatorSpacing sniff, although the default value of
allowMultipleArguments
is changed.
See the Squiz.WhiteSpace.OperatorSpacing sniff for an explanation of all properties.
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.3.5 |
Note: The
indent
property is inherited from the PSR2.Classes.ClassDeclaration sniff.
One of the rules that this sniff enforces is the indent of a list of implemented or extended class names that have been split over multiple lines. By default, this sniff ensures that the class names are indented 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="Squiz.Classes.ClassDeclaration">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
minimumVisibility | string | private | 3.6.0 |
Note: The
minimumVisibility
property is inherited from the PEAR.Commenting.FunctionComment sniff.
This sniff verifies that functions are documented using a docblock. By default, all functions are checked regardless of their visibility, but the sniff can be told to ignore private and protected functions using the minimumVisibility
property. When set to protected
, only public and protected functions will be checked. When set to public
, only public functions will be checked.
<rule ref="Squiz.Commenting.FunctionComment">
<properties>
<property name="minimumVisibility" value="public" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
lineLimit | int | 20 | 2.7.0 |
commentFormat | string | //end %s | 2.7.0 |
This sniff checks that long blocks of code have a closing comment. The lineLimit
property allows you to configure the numbers of lines that the code block must span before requiring a comment. By default, the code block must be at least 20 lines long, including the opening and closing lines, but you can change the required length by setting the lineLimit
property.
<rule ref="Squiz.Commenting.LongConditionClosingComment">
<properties>
<property name="lineLimit" value="40" />
</properties>
</rule>
When a closing comment is required, the format defaults to //end %s
, where the %s placeholder is replaced with the type of the code block. For example, //end if
, //end foreach
, or //end switch
. You can change the format of the end comment by setting the commentFormat
property.
<!-- Have code block comments look like // end foreach() etc. -->
<rule ref="Squiz.Commenting.LongConditionClosingComment">
<properties>
<property name="commentFormat" value="// end %s()" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
requiredSpacesBeforeColon | int | 1 | 3.2.0 |
One of the rules this sniff enforces is the number of spaces before the opening brace of control structures. By default, the sniff ensures there is one space before the opening brace for control structures using standard syntax, and one space before the colon for control structures using alternative syntax, as shown in the following code snippet:
if ($foo) :
// IF body.
else :
// ELSE body.
endif;
A common way of defining control structures using alternative syntax is to put no padding before the colon, as shown in the following code snippet:
if ($foo):
// IF body.
else:
// ELSE body.
endif;
If you prefer to write your code like this, you can set the requiredSpacesBeforeColon
property to 0
.
<rule ref="Squiz.ControlStructures.ControlSignature">
<properties>
<property name="requiredSpacesBeforeColon" value="0" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
requiredSpacesAfterOpen | int | 0 | 1.5.2 |
requiredSpacesBeforeClose | int | 0 | 1.5.2 |
This sniff checks that foreach
structures have the correct padding inside their bracketed statement. By default, the sniff ensures there are zero spaces following the opening bracket, and zero spaces preceding the closing bracket, as shown in the following code snippet:
foreach ($foo as $bar) {
// Body.
}
Another common way of padding control structures is to use a single space, as shown in the following code snippet:
foreach ( $foo as $bar ) {
// Body.
}
If you prefer to write your code like this, you can set the requiredSpacesAfterOpen
and requiredSpacesBeforeClose
properties to 1
, or whatever padding you prefer.
<rule ref="Squiz.ControlStructures.ForEachLoopDeclaration">
<properties>
<property name="requiredSpacesAfterOpen" value="1" />
<property name="requiredSpacesBeforeClose" value="1" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
requiredSpacesAfterOpen | int | 0 | 1.5.2 |
requiredSpacesBeforeClose | int | 0 | 1.5.2 |
ignoreNewlines | bool | false | 3.5.4 |
This sniff checks that for
structures have the correct padding inside their bracketed statement. By default, the sniff ensures there are zero spaces following the opening bracket, and zero spaces preceding the closing bracket, as shown in the following code snippet:
for ($i = 0; $i < 10; $i++) {
// Body.
}
Another common way of padding control structures is to use a single space, as shown in the following code snippet:
for ( $i = 0; $i < 10; $i++ ) {
// Body.
}
If you prefer to write your code like this, you can set the requiredSpacesAfterOpen
and requiredSpacesBeforeClose
properties to 1
, or whatever padding you prefer.
<rule ref="Squiz.ControlStructures.ForLoopDeclaration">
<properties>
<property name="requiredSpacesAfterOpen" value="1" />
<property name="requiredSpacesBeforeClose" value="1" />
</properties>
</rule>
Sometimes long control structures are broken over multiple lines to work within a maximum line length, but this sniff will generate an error for these cases by default. Setting the ignoreNewlines
property to true
will allow newline characters before, after, and between each of the three bracketed statements.
<rule ref="Squiz.ControlStructures.ForLoopDeclaration">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.4.7 |
Two of the rules that this sniff enforces are the indent of case
and default
keywords, and the indent of the case terminating statement. By default, this sniff ensures that the keywords and terminating statement are indented 4 spaces from the switch
keyword, but you can change the size of the indent by setting the indent
property.
<rule ref="Squiz.ControlStructures.SwitchDeclaration">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
error | bool | true | 1.4.6 |
If the error
property is set to false
, a warning will be thrown for violations instead of an error.
<rule ref="Squiz.CSS.ForbiddenStyles">
<properties>
<property name="error" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
indent | int | 4 | 1.4.7 |
This sniff checks the indentation of CSS class definitions. By default, this sniff ensures that style statements are indented using 4 spaces, but you can change the size of the indent by setting the indent
property.
<rule ref="Squiz.CSS.Indentation">
<properties>
<property name="indent" value="2" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
ignoreComments | bool | false | 1.4.0 |
Note: The
ignoreComments
property is inherited from the AbstractPattern sniff.
This sniff verifies that functions declarations match a specific pattern of whitespace and bracket placement. By default, comments placed within the function declaration will generate an error, but the sniff can be told to ignore comments by setting the ignoreComments
property to true
.
<rule ref="Squiz.Functions.FunctionDeclaration">
<properties>
<property name="ignoreComments" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
equalsSpacing | int | 0 | 1.3.5 |
requiredSpacesAfterOpen | int | 0 | 1.5.2 |
requiredSpacesBeforeClose | int | 0 | 1.5.2 |
One of the rules this sniff enforces is the padding around equal signs in the function argument list. By default, the sniff ensures there are zero spaces before and after the equals sign, as shown in the following code snippet:
function foo($a='a', $b='b') {
// Body.
}
Another common way of defining default values is to use a single space, as shown in the following code snippet:
function foo($a = 'a', $b = 'b') {
// Body.
}
If you prefer to write your code like this, you can set the equalsSpacing
property to 1
, or whatever padding you prefer.
<rule ref="Squiz.Functions.FunctionDeclarationArgumentSpacing">
<properties>
<property name="equalsSpacing" value="1" />
</properties>
</rule>
Another of the rules this sniff enforces is that functions have the correct padding inside their bracketed list of arguments. By default, the sniff ensures there are zero spaces following the opening bracket, and zero spaces preceding the closing bracket, as shown in the following code snippet:
function foo($a, $b) {
// Body.
}
Another common way of padding argument lists is to use a single space, as shown in the following code snippet:
function foo( $a, $b ) {
// Body.
}
If you prefer to write your code like this, you can set the requiredSpacesAfterOpen
and requiredSpacesBeforeClose
properties to 1
, or whatever padding you prefer.
<rule ref="Squiz.Functions.FunctionDeclarationArgumentSpacing">
<properties>
<property name="requiredSpacesAfterOpen" value="1" />
<property name="requiredSpacesBeforeClose" value="1" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
maxPercentage | int | 35 | 1.3.3 |
This sniff generates warnings for commented out code. By default, a warning is generated if a comment appears to be more than 35% valid code. If you find that the sniff is generating a lot of false positive, you may want to raise the valid code threshold by increasing the maxPercentage
property. Similarly, if you find that the sniff is generating a lot of false negatives, you may want to make it more sensitive by dropping the threshold by decreasing the maxPercentage
property.
<!-- Make this sniff more sensitive to commented out code blocks. -->
<rule ref="Squiz.PHP.CommentedOutCode">
<properties>
<property name="maxPercentage" value="20" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
error | bool | false | - |
Note: This sniff also has a
forbiddenFunctions
property inherited from the Generic.PHP.ForbiddenFunctions sniff, but it should not be used. If you want to customise the list of discouraged functions, use the Generic.PHP.ForbiddenFunctions sniff directly.
If the error
property is set to true
, an error will be thrown for violations instead of a warning.
<rule ref="Squiz.PHP.DiscouragedFunctions">
<properties>
<property name="error" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
error | bool | false | - |
Note: This sniff also has a
forbiddenFunctions
property inherited from the Generic.PHP.ForbiddenFunctions sniff, but it should not be used. If you want to customise the list of forbidden functions, use the Generic.PHP.ForbiddenFunctions sniff directly.
If the error
property is set to true
, an error will be thrown for violations instead of a warning.
<rule ref="Squiz.PHP.ForbiddenFunctions">
<properties>
<property name="error" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
spacing | int | 0 | 2.0.0 |
ignoreNewlines | bool | false | 2.3.1 |
One of the rules this sniff enforces is the padding around concatenation operators. By default, the sniff ensures there are zero spaces before and after the concatenation operator, as shown in the following code snippet:
$foo = $number.'-'.$letter;
Another common way of padding concatenation operators is to use a single space, as shown in the following code snippet:
$foo = $number . '-' . $letter;
If you prefer to write your code like this, you can set the spacing
property to 1
, or whatever padding you prefer.
<rule ref="Squiz.Strings.ConcatenationSpacing">
<properties>
<property name="spacing" value="1" />
</properties>
</rule>
Sometimes long concatenation statements are broken over multiple lines to work within a maximum line length, but this sniff will generate an error for these cases by default. Setting the ignoreNewlines
property to true
will allow newline characters before or after a concatenation operator, and any required padding for alignment.
<rule ref="Squiz.Strings.ConcatenationSpacing">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
spacing | int | 2 | 1.4.5 |
spacingBeforeFirst | int | 2 | 3.3.0 |
spacingAfterLast | int | 2 | 3.3.0 |
This sniff checks that there are two blank lines before and after functions declarations, but you can change the required padding using the spacing
, spacingBeforeFirst
, and spacingAfterLast
properties.
The spacingBeforeFirst
property is used to determine how many blank lines are required before a function when it is the first block of code inside a statement group or control structure. This property is ignored when the function is outside one of these scopes, or if the function is preceded by member vars. If this property has not been set, the sniff will use whatever value has been set for the spacing
property.
The spacingAfterLast
property is used to determine how many blank lines are required after a function when it is the last block of code inside a statement group or control structure. This property is ignored when the function is outside one of these scopes, or if any member vars are placed after the function. If this property has not been set, the sniff will use whatever value has been set for the spacing
property.
The spacing
property applies in all other cases.
<!-- Ensure 1 blank line before and after functions, except at the top and bottom. -->
<rule ref="Squiz.WhiteSpace.FunctionSpacing">
<properties>
<property name="spacing" value="1" />
<property name="spacingBeforeFirst" value="0" />
<property name="spacingAfterLast" value="0" />
</properties>
</rule>
As the spacingBeforeFirst
and spacingAfterLast
properties use the value of the spacing
property when not set, a shortcut for setting all three properties to the same value is to specify a value for the spacing
property only.
<!-- Ensure 1 blank line before and after functions in all cases. -->
<rule ref="Squiz.WhiteSpace.FunctionSpacing">
<properties>
<property name="spacing" value="1" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
spacing | int | 1 | 3.1.0 |
spacingBeforeFirst | int | 1 | 3.1.0 |
This sniff checks that there is one blank line before between member vars and before the fist member var, but you can change the required padding using the spacing
and spacingBeforeFirst
properties.
<!--
Ensure 2 blank lines between member vars,
but don't require blank lines before the first.
-->
<rule ref="Squiz.WhiteSpace.MemberVarSpacing">
<properties>
<property name="spacing" value="2" />
<property name="spacingBeforeFirst" value="0" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
ignoreNewlines | bool | false | 2.7.0 |
This sniff ensures there are no spaces surrounding an object operator. Sometimes long object chains are broken over multiple lines to work within a maximum line length, but this sniff will generate an error for these cases by default. Setting the ignoreNewlines
property to true
will allow newline characters before or after an object operator, and any required padding for alignment.
<rule ref="Squiz.WhiteSpace.ObjectOperatorSpacing">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
ignoreNewlines | bool | false | 2.2.0 |
ignoreSpacingBeforeAssignments | bool | true | 3.5.0 |
This sniff ensures there is one space before and after an operator. Sometimes long statements are broken over multiple lines to work within a maximum line length, but this sniff will generate an error for these cases by default. Setting the ignoreNewlines
property to true
will allow newline characters before or after an operator, and any required padding for alignment.
<rule ref="Squiz.WhiteSpace.OperatorSpacing">
<properties>
<property name="ignoreNewlines" value="true" />
</properties>
</rule>
A number of coding standards allow multiple assignments to be aligned inside a single code block. When doing this, the number of spaces before an assignment operator can be greater than 1
. To support this coding style, this sniff does not check the spacing before assignment operators by default. If you do not want to allow multiple assignments to be aligned, you can enable checking of spacing before assignment operators by setting the ignoreSpacingBeforeAssignments
property to false
.
<rule ref="Squiz.WhiteSpace.OperatorSpacing">
<properties>
<property name="ignoreSpacingBeforeAssignments" value="false" />
</properties>
</rule>
Property Name | Type | Default | Available Since |
---|---|---|---|
ignoreBlankLines | bool | false | 1.4.2 |
Some of the rules this sniff enforces are that there should not be whitespace at the end of a line, and that functions should not contain multiple blank lines in a row. If the ignoreBlankLines
property is set to true
, blank lines (lines that contain only whitespace) may have spaces and tabs as their content, and multiple blank lines will be allows inside functions.
<rule ref="Squiz.WhiteSpace.SuperfluousWhitespace">
<properties>
<property name="ignoreBlankLines" value="true" />
</properties>
</rule>
For everyone
Introduction
Requirements
Usage
Advanced Usage
Reporting
Configuration Options
Fixing Errors Automatically
FAQ
For coding standard creators
Annotated Ruleset
Customisable Sniff Properties
For sniff developers
Coding Standard Tutorial
Version 3.0 Upgrade Guide
Version 1.3.0 Upgrade Guide