Skip to content

lint: best-practices/no-boolean-literal-comparison shouldn't always be thrown for === false #129

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
giorgiopogliani opened this issue Mar 8, 2025 · 5 comments
Assignees
Labels
Status: Closed This issue is closed and no more work is planned. Type: Bug An issue causing unintended or problematic behavior.

Comments

@giorgiopogliani
Copy link

giorgiopogliani commented Mar 8, 2025

🐞 Describe the Bug

Some php functions returns a union type like json_encode that has return type string|false, so it's should be valid behaviour comparing it to false with the strict equal.

Of course many other functions have this behaviour this is just an example.

🔄 Steps to Reproduce

  1. create a test.php with the example
  2. run mago lint test.php

⚙️ Configuration (mago.toml)

none

📜 Command Output

warning[best-practices/no-boolean-literal-comparison]: Avoid comparing the boolean literal `false`.
  ┌─ test.php:7:29
  │
7 │ if (json_encode('test') === false) {
  │     ------------------------^^^^^
  │     │                       │
  │     │                       Boolean literal `false` is used here.
  │     Revise the logic to avoid using a boolean literal.
  │
  = Comparisons with a boolean literal can be error-prone.
  = Help: Review and adjust the logic to remove the boolean literal comparison.

warning: found 1 issues: 1 warning(s)

📂 PHP Code Sample (If Applicable)

<?php

if (json_encode('test') === false) {
    echo 'Error';
}

🖥️ Operating System

Linux

📦 How did you install Mago?

Homebrew (brew install mago)

📝 Additional Context

No response

@giorgiopogliani giorgiopogliani added the Type: Bug An issue causing unintended or problematic behavior. label Mar 8, 2025
@innocenzi
Copy link
Contributor

I'm also confused by this rule. I have several reports. I'm wondering if the rule was supposed to check for literal boolean strings (eg. 'false' and not false)?

[$isValid, $message] = match (true) {
    is_string($result) => [false, $result],
    $result === false => [false, 'Value did not pass validation.'],
    default => [true, ''],
};
warning[best-practices/no-boolean-literal-comparison]: Avoid comparing the boolean literal `false`.
   ┌─ src/Tempest/Validation/src/Validator.php:69:25
   │
69 │             $result === false => [false, 'Value did not pass validation.'],
   │             ------------^^^^^
   │             │           │
   │             │           Boolean literal `false` is used here.
   │             Revise the logic to avoid using a boolean literal.
   │
   = Comparisons with a boolean literal can be error-prone.
   = Help: Review and adjust the logic to remove the boolean literal comparison.

if ($result === false) {
    return [];
}
warning[best-practices/no-boolean-literal-comparison]: Avoid comparing the boolean literal `false`.
   ┌─ src/Tempest/Support/src/Regex/functions.php:28:29
   │
28 │             if ($result === false || $result === 0) {
   │                 ------------^^^^^
   │                 │           │
   │                 │           Boolean literal `false` is used here.
   │                 Revise the logic to avoid using a boolean literal.
   │
   = Comparisons with a boolean literal can be error-prone.
   = Help: Review and adjust the logic to remove the boolean literal comparison.

@azjezz
Copy link
Member

azjezz commented Mar 10, 2025

This rule is meant to force you to write !$bar instead of $bar === false, i understand that some PHP builtin functions return T|false where this won't be possible, and i think in those cases the best course of action is to either disable the rule, or use @mago-expect to avoid the report.

@giorgiopogliani
Copy link
Author

@azjezz Maybe we can change it to be opt-in? I would basically disable it in every project if the behaviour can't change

@innocenzi
Copy link
Contributor

I agree that this should be better opt-in given its current behavior

@azjezz azjezz closed this as completed in fe26c72 Mar 13, 2025
@azjezz azjezz added the Status: Closed This issue is closed and no more work is planned. label Mar 13, 2025
@azjezz
Copy link
Member

azjezz commented Mar 13, 2025

the rule is now disabled by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Closed This issue is closed and no more work is planned. Type: Bug An issue causing unintended or problematic behavior.
Projects
None yet
Development

No branches or pull requests

3 participants