Showing 426 of 426 total issues
Avoid assigning values to variables in if clauses and the like (line '190', column '7'). Open
public static function purge($id)
{
if ($dbid = self::dbid($id))
{
return Data::deleteById($dbid);
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid assigning values to variables in if clauses and the like (line '28', column '7'). Open
public static function edit($is_add = false, $users = array(), $current_user_id = NULL)
{
$item = array();
if ($id = intval(Input::get('id')))
{
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid unused parameters such as '$is_index'. Open
public static function report($base_url, $is_index = false)
- Read upRead up
- Exclude checks
UnusedFormalParameter
Since: 0.2
Avoid passing parameters to methods or constructors and then not using those parameters.
Example
class Foo
{
private function bar($howdy)
{
// $howdy is not used
}
}
Source https://phpmd.org/rules/unusedcode.html#unusedformalparameter
Avoid assigning values to variables in if clauses and the like (line '86', column '34'). Open
public static function isIgnorable($str)
{
$attrs = Element\Get::attributes($str);
// Strictly this is not so correct. but it seems be considered.
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid assigning values to variables in if clauses and the like (line '124', column '9'). Open
private static function recognitionCharset($html)
{
$str = Element::ignoreElementsByStr($html);
// Do not use Element\Get::elementsByRe() because crashed character cause bad cache
preg_match_all("/\<([a-zA-Z1-6]+?) +?([^\>]*?)[\/]*?\>|\<([a-zA-Z1-6]+?)[ \/]*?\>/i", $str, $ms);
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid assigning values to variables in if clauses and the like (line '173', column '7'). Open
public static function updatePartial($id, $key, $value)
{
if ($dbid = self::dbid($id))
{
$vals = static::fetch($dbid, true);
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid assigning values to variables in if clauses and the like (line '289', column '7'). Open
private static function changeSite()
{
if ($site = Input::post('site'))
{
if ($site != Model\Data::groupId())
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid assigning values to variables in if clauses and the like (line '254', column '7'). Open
private static function addNewSite($sites)
{
if ($new_site = Input::post('new_site', false))
{
if (in_array($new_site, $sites))
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid assigning values to variables in if clauses and the like (line '87', column '37'). Open
public static function isIgnorable($str)
{
$attrs = Element\Get::attributes($str);
// Strictly this is not so correct. but it seems be considered.
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid assigning values to variables in if clauses and the like (line '94', column '10'). Open
private static function setCommonIssue($issues, $commons)
{
foreach ($commons as $v)
{
foreach ($v as $vv)
- Read upRead up
- Exclude checks
IfStatementAssignment
Since: 2.7.0
Assignments in if clauses and the like are considered a code smell. Assignments in PHP return the right operand as their result. In many cases, this is an expected behavior, but can lead to many difficult to spot bugs, especially when the right operand could result in zero, null or an empty string and the like.
Example
class Foo
{
public function bar($flag)
{
if ($foo = 'bar') { // possible typo
// ...
}
if ($baz = 0) { // always false
// ...
}
}
}
Source http://phpmd.org/rules/cleancode.html#ifstatementassignment
Avoid using Kontiki\count() function in while loops. Open
while (count($keys) > 1)
{
$key = array_shift($keys);
if ( ! isset($array[$key]) or ! is_array($array[$key]))
- Read upRead up
- Exclude checks
CountInLoopExpression
Since: 2.7.0
Using count/sizeof in loops expressions is considered bad practice and is a potential source of many bugs, especially when the loop manipulates an array, as count happens on each iteration.
Example
class Foo {
public function bar()
{
$array = array();
for ($i = 0; count($array); $i++) {
// ...
}
}
}
Source https://phpmd.org/rules/design.html#countinloopexpression
server accesses the super-global variable $_SERVER. Open
public static function server(
$index,
$default = null,
$filter = FILTER_DEFAULT,
$options = array()
- Read upRead up
- Exclude checks
Superglobals
Since: 0.2
Accessing a super-global variable directly is considered a bad practice. These variables should be encapsulated in objects that are provided by a framework, for instance.
Example
class Foo {
public function bar() {
$name = $_POST['foo'];
}
}
Source
file accesses the super-global variable $_FILES. Open
public static function file($index = null, $default = null)
{
$files = $_FILES;
if (func_num_args() === 0)
- Read upRead up
- Exclude checks
Superglobals
Since: 0.2
Accessing a super-global variable directly is considered a bad practice. These variables should be encapsulated in objects that are provided by a framework, for instance.
Example
class Foo {
public function bar() {
$name = $_POST['foo'];
}
}
Source
removeQueryStrings accesses the super-global variable $_GET. Open
public static function removeQueryStrings($uri, $query_strings = array())
{
if (strpos($uri, '?') !== false)
{
// all query strings
- Read upRead up
- Exclude checks
Superglobals
Since: 0.2
Accessing a super-global variable directly is considered a bad practice. These variables should be encapsulated in objects that are provided by a framework, for instance.
Example
class Foo {
public function bar() {
$name = $_POST['foo'];
}
}
Source
server accesses the super-global variable $_SERVER. Open
public static function server(
$index,
$default = null,
$filter = FILTER_DEFAULT,
$options = array()
- Read upRead up
- Exclude checks
Superglobals
Since: 0.2
Accessing a super-global variable directly is considered a bad practice. These variables should be encapsulated in objects that are provided by a framework, for instance.
Example
class Foo {
public function bar() {
$name = $_POST['foo'];
}
}
Source
Unreachable code. Open
checks = $imprements.find(':checked').parent().map(function(){
- Read upRead up
- Exclude checks
disallow unreachable code after return
, throw
, continue
, and break
statements (no-unreachable)
Because the return
, throw
, break
, and continue
statements unconditionally exit a block of code, any statements after them cannot be executed. Unreachable statements are usually a mistake.
function fn() {
x = 1;
return x;
x = 3; // this will never execute
}
Rule Details
This rule disallows unreachable code after return
, throw
, continue
, and break
statements.
Examples of incorrect code for this rule:
/*eslint no-unreachable: "error"*/
function foo() {
return true;
console.log("done");
}
function bar() {
throw new Error("Oops!");
console.log("done");
}
while(value) {
break;
console.log("done");
}
throw new Error("Oops!");
console.log("done");
function baz() {
if (Math.random() < 0.5) {
return;
} else {
throw new Error();
}
console.log("done");
}
for (;;) {}
console.log("done");
Examples of correct code for this rule, because of JavaScript function and variable hoisting:
/*eslint no-unreachable: "error"*/
function foo() {
return bar();
function bar() {
return 1;
}
}
function bar() {
return x;
var x;
}
switch (foo) {
case 1:
break;
var x;
}
Source: http://eslint.org/docs/rules/
Unreachable code. Open
$default_situations.each(function(index){
- Read upRead up
- Exclude checks
disallow unreachable code after return
, throw
, continue
, and break
statements (no-unreachable)
Because the return
, throw
, break
, and continue
statements unconditionally exit a block of code, any statements after them cannot be executed. Unreachable statements are usually a mistake.
function fn() {
x = 1;
return x;
x = 3; // this will never execute
}
Rule Details
This rule disallows unreachable code after return
, throw
, continue
, and break
statements.
Examples of incorrect code for this rule:
/*eslint no-unreachable: "error"*/
function foo() {
return true;
console.log("done");
}
function bar() {
throw new Error("Oops!");
console.log("done");
}
while(value) {
break;
console.log("done");
}
throw new Error("Oops!");
console.log("done");
function baz() {
if (Math.random() < 0.5) {
return;
} else {
throw new Error();
}
console.log("done");
}
for (;;) {}
console.log("done");
Examples of correct code for this rule, because of JavaScript function and variable hoisting:
/*eslint no-unreachable: "error"*/
function foo() {
return bar();
function bar() {
return 1;
}
}
function bar() {
return x;
var x;
}
switch (foo) {
case 1:
break;
var x;
}
Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if( $('.a11yc_section_criterion').length == 1 )
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
criterion_val = $criterion.val() == '' ? 0 : $criterion.val(),
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/
Expected '===' and instead saw '=='. Open
if( index == 0 )
- Read upRead up
- Exclude checks
Require === and !== (eqeqeq)
It is considered good practice to use the type-safe equality operators ===
and !==
instead of their regular counterparts ==
and !=
.
The reason for this is that ==
and !=
do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm.
For instance, the following statements are all considered true
:
[] == false
[] == ![]
3 == "03"
If one of those occurs in an innocent-looking statement such as a == b
the actual problem is very difficult to spot.
Rule Details
This rule is aimed at eliminating the type-unsafe equality operators.
Examples of incorrect code for this rule:
/*eslint eqeqeq: "error"*/
if (x == 42) { }
if ("" == text) { }
if (obj.getStuff() != undefined) { }
The --fix
option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof
expression, or if both operands are literals with the same type.
Options
always
The "always"
option (default) enforces the use of ===
and !==
in every situation (except when you opt-in to more specific handling of null
[see below]).
Examples of incorrect code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
Examples of correct code for the "always"
option:
/*eslint eqeqeq: ["error", "always"]*/
a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null
This rule optionally takes a second argument, which should be an object with the following supported properties:
-
"null"
: Customize how this rule treatsnull
literals. Possible values:-
always
(default) - Always use === or !==. -
never
- Never use === or !== withnull
. -
ignore
- Do not apply this rule tonull
.
-
smart
The "smart"
option enforces the use of ===
and !==
except for these cases:
- Comparing two literal values
- Evaluating the value of
typeof
- Comparing against
null
Examples of incorrect code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
// comparing two variables requires ===
a == b
// only one side is a literal
foo == true
bananas != 1
// comparing to undefined requires ===
value == undefined
Examples of correct code for the "smart"
option:
/*eslint eqeqeq: ["error", "smart"]*/
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null
allow-null
Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null
literal.
["error", "always", {"null": "ignore"}]
When Not To Use It
If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/