yiisoft/yii2

View on GitHub

Showing 2,034 of 2,034 total issues

Expected '===' and instead saw '=='.
Open

                var isString = typeof value == 'string' || value instanceof String;
Severity: Minor
Found in framework/assets/yii.validation.js by eslint

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 treats null literals. Possible values:
    • always (default) - Always use === or !==.
    • never - Never use === or !== with null.
    • ignore - Do not apply this rule to null.

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 (options.dataType == 'jsonp') {
Severity: Minor
Found in framework/assets/yii.js by eslint

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 treats null literals. Possible values:
    • always (default) - Always use === or !==.
    • never - Never use === or !== with null.
    • ignore - Do not apply this rule to null.

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

                    valid = value != compareValue;
Severity: Minor
Found in framework/assets/yii.validation.js by eslint

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 treats null literals. Possible values:
    • always (default) - Always use === or !==.
    • never - Never use === or !== with null.
    • ignore - Do not apply this rule to null.

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

            var valid = !options.strict && (value == options.trueValue || value == options.falseValue)
Severity: Minor
Found in framework/assets/yii.validation.js by eslint

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 treats null literals. Possible values:
    • always (default) - Always use === or !==.
    • never - Never use === or !== with null.
    • ignore - Do not apply this rule to null.

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/

Move the invocation into the parens that contain the function.
Open

yii.validation = (function ($) {
Severity: Minor
Found in framework/assets/yii.validation.js by eslint

Require IIFEs to be Wrapped (wrap-iife)

You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.

// function expression could be unwrapped
var x = function () { return { y: 1 };}();

// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError

Rule Details

This rule requires all immediately-invoked function expressions to be wrapped in parentheses.

Options

This rule has two options, a string option and an object option.

String option:

  • "outside" enforces always wrapping the call expression. The default is "outside".
  • "inside" enforces always wrapping the function expression.
  • "any" enforces always wrapping, but allows either style.

Object option:

  • "functionPrototypeMethods": true additionally enforces wrapping function expressions invoked using .call and .apply. The default is false.

outside

Examples of incorrect code for the default "outside" option:

/*eslint wrap-iife: ["error", "outside"]*/

var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression

Examples of correct code for the default "outside" option:

/*eslint wrap-iife: ["error", "outside"]*/

var x = (function () { return { y: 1 };}()); // wrapped call expression

inside

Examples of incorrect code for the "inside" option:

/*eslint wrap-iife: ["error", "inside"]*/

var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression

Examples of correct code for the "inside" option:

/*eslint wrap-iife: ["error", "inside"]*/

var x = (function () { return { y: 1 };})(); // wrapped function expression

any

Examples of incorrect code for the "any" option:

/*eslint wrap-iife: ["error", "any"]*/

var x = function () { return { y: 1 };}(); // unwrapped

Examples of correct code for the "any" option:

/*eslint wrap-iife: ["error", "any"]*/

var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression

functionPrototypeMethods

Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true } options:

/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */

var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))

Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true } options:

/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */

var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)

Source: http://eslint.org/docs/rules/

The variable $_mimeAliases is not named in camelCase.
Open

    protected static function loadMimeAliases($aliasesFile)
    {
        if ($aliasesFile === null) {
            $aliasesFile = static::$mimeAliasesFile;
        }
Severity: Minor
Found in framework/helpers/BaseFileHelper.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_mimeAliases is not named in camelCase.
Open

    protected static function loadMimeAliases($aliasesFile)
    {
        if ($aliasesFile === null) {
            $aliasesFile = static::$mimeAliasesFile;
        }
Severity: Minor
Found in framework/helpers/BaseFileHelper.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_icuShortFormats is not named in camelCase.
Open

    public static function convertDateIcuToPhp($pattern, $type = 'date', $locale = null)
    {
        if (isset(self::$_icuShortFormats[$pattern])) {
            if (extension_loaded('intl')) {
                if ($locale === null) {

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_icuShortFormats is not named in camelCase.
Open

    public static function convertDateIcuToPhp($pattern, $type = 'date', $locale = null)
    {
        if (isset(self::$_icuShortFormats[$pattern])) {
            if (extension_loaded('intl')) {
                if ($locale === null) {

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_reusableData is not named in camelCase.
Open

    public function isChanged($cache)
    {
        if ($this->reusable) {
            $hash = $this->generateReusableHash();
            if (!array_key_exists($hash, self::$_reusableData)) {
Severity: Minor
Found in framework/caching/Dependency.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_mimeTypes is not named in camelCase.
Open

    protected static function loadMimeTypes($magicFile)
    {
        if ($magicFile === null) {
            $magicFile = static::$mimeMagicFile;
        }
Severity: Minor
Found in framework/helpers/BaseFileHelper.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_icuShortFormats is not named in camelCase.
Open

    public static function convertDateIcuToJui($pattern, $type = 'date', $locale = null)
    {
        if (isset(self::$_icuShortFormats[$pattern])) {
            if (extension_loaded('intl')) {
                if ($locale === null) {

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_icuShortFormats is not named in camelCase.
Open

    public static function convertDateIcuToJui($pattern, $type = 'date', $locale = null)
    {
        if (isset(self::$_icuShortFormats[$pattern])) {
            if (extension_loaded('intl')) {
                if ($locale === null) {

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_mimeAliases is not named in camelCase.
Open

    protected static function loadMimeAliases($aliasesFile)
    {
        if ($aliasesFile === null) {
            $aliasesFile = static::$mimeAliasesFile;
        }
Severity: Minor
Found in framework/helpers/BaseFileHelper.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_icuShortFormats is not named in camelCase.
Open

    public static function convertDateIcuToPhp($pattern, $type = 'date', $locale = null)
    {
        if (isset(self::$_icuShortFormats[$pattern])) {
            if (extension_loaded('intl')) {
                if ($locale === null) {

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_icuShortFormats is not named in camelCase.
Open

    public static function convertDateIcuToPhp($pattern, $type = 'date', $locale = null)
    {
        if (isset(self::$_icuShortFormats[$pattern])) {
            if (extension_loaded('intl')) {
                if ($locale === null) {

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_mimeTypes is not named in camelCase.
Open

    protected static function loadMimeTypes($magicFile)
    {
        if ($magicFile === null) {
            $magicFile = static::$mimeMagicFile;
        }
Severity: Minor
Found in framework/helpers/BaseFileHelper.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_icuShortFormats is not named in camelCase.
Open

    public static function convertDateIcuToJui($pattern, $type = 'date', $locale = null)
    {
        if (isset(self::$_icuShortFormats[$pattern])) {
            if (extension_loaded('intl')) {
                if ($locale === null) {

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_reusableData is not named in camelCase.
Open

    public function evaluateDependency($cache)
    {
        if ($this->reusable) {
            $hash = $this->generateReusableHash();
            if (!array_key_exists($hash, self::$_reusableData)) {
Severity: Minor
Found in framework/caching/Dependency.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

The variable $_mimeTypes is not named in camelCase.
Open

    protected static function loadMimeTypes($magicFile)
    {
        if ($magicFile === null) {
            $magicFile = static::$mimeMagicFile;
        }
Severity: Minor
Found in framework/helpers/BaseFileHelper.php by phpmd

Since: PHPMD 0.2

It is considered best practice to use the camelCase notation to name variables.

Example:

class ClassName {
      public function doSomething() {
          $data_module = new DataModule();
      }
  }

Source: http://phpmd.org/rules/controversial.txt

Severity
Category
Status
Source
Language