Skip to content
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

Implement AssertEqualsIsDiscouragedRule #216

Merged
merged 4 commits into from
Dec 17, 2024
Merged

Conversation

staabm
Copy link
Contributor

@staabm staabm commented Dec 10, 2024

Simplified version which is concentrated on the main point: point people to assertSame when possible.
I intentionally stripped of the "assertEquals is fine when a comment is given" case, as I think its not important.

closes #6

refs #7

@staabm staabm changed the title Implement AssertSameOverAssertEqualsRule Implement AssertEqualsIsDiscouragedRule Dec 10, 2024
@staabm staabm marked this pull request as ready for review December 10, 2024 11:06
@ondrejmirtes
Copy link
Member

I don't think we should do this here. It'd only make sense when combined with strict-rules.

@staabm
Copy link
Contributor Author

staabm commented Dec 12, 2024

Do you mean this rule should move into the strict rules repo?

Or do you mean I should somehow detect whether strict rules are loaded in tandem and skip the rule if not?

@ondrejmirtes
Copy link
Member

We could do it similarly to deprecationRulesInstalled parameter which is used here I think.

@staabm
Copy link
Contributor Author

staabm commented Dec 13, 2024

I think it should be good to go now

rules.neon Outdated
-
class: PHPStan\Rules\PHPUnit\AssertEqualsIsDiscouragedRule
arguments:
strictRulesInstalled: %strictRulesInstalled%
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather use conditionalTags instead of passing the parameter in the rule.

Also: we can do it only on bleeding edge. Conditional tags can do and condition based on multiple parameters since phpstan/phpstan-src#1697 (see the tests).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL, thanks


public function getNodeType(): string
{
return NodeAbstract::class;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like they have a more specific class parent than just NodeAbstract. Feel free to check out and optimize other similar rules as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed here and will do for more rules in a separate PR with a 1.4.x target in #217

@ondrejmirtes ondrejmirtes merged commit 10880da into phpstan:2.0.x Dec 17, 2024
31 checks passed
@ondrejmirtes
Copy link
Member

Thank you.

@staabm staabm deleted the equ branch December 17, 2024 17:26
@VincentLanglet
Copy link
Contributor

Hi @staabm, just saw this new rules.

I feel like it should be stricter.
Reporting AssertEquals($int, $int) is kinda useless since there is no risk of error here.
What could be useful would be to report thing like AssertEquals($string, $int) or AssertEquals($string, null) when both values are scalar, even if it's not the same type.

It's like if we were reporting $string == $string but not null == $string, which is currently the case with strict-rules
https://phpstan.org/r/d4a18742-8e2c-40fa-97a9-7e0e8440106a

Enforcing a stricter comparison, like '' === $string... is better. Here would be the same, we're enforcing AssertSame($string,'') rather than AssertEquals($string, null). WDYT ?

@staabm
Copy link
Contributor Author

staabm commented Dec 18, 2024

the goal of this PRs rule is about reporting assertions which can use strict-comparison without risk (unnecessary loose comparision).

I feel like it should be stricter.
Reporting AssertEquals($int, $int) is kinda useless since there is no risk of error here.
What could be useful would be to report thing like AssertEquals($string, $int) or AssertEquals($string, null) when both values are scalar, even if it's not the same type.

I think what you are suggesting is about "always true/false" errors (so verification of arguments given to AssertEquals) which sounds like a separate rule (maybe its even already implemented.. did not check)

@VincentLanglet
Copy link
Contributor

the goal of this PRs rule is about reporting assertions which can use strict-comparison without risk (unnecessary loose comparision).

I understood that, but then it doesn't require to be behind the strictRulesInstalled flag IMHO.

There is already rules asking to change things like

  • AssertSame(true, $foo) to AssertTrue($foo)
  • AssertSame(42, count($foo)) to AssertCount(42, $foo)
  • ...

All these changes are safe. And not behind the strictRulesInstalled flag.

I would think that

  • Changing AssertEqual($scalarType, $sameScalarType) to AssertSame($scalarType, $sameScalarType) wouldn't require strictRulesInstalled
  • Changing AssertEqual($scalarType, $differentScalarType) to AssertSame($scalarType, $differentScalarType) would require strictRulesInstalled since it's not safe

The same way $foo == $bar is reported as error by strictRule, even if it's not safe to change it to ===.

@staabm
Copy link
Contributor Author

staabm commented Dec 18, 2024

I understood that, but then it doesn't require to be behind the strictRulesInstalled flag IMHO.

AssertEqualsIsDiscouragedRule is about loose comparison, which is a strict-rules thing.

  • AssertSame(true, $foo) to AssertTrue($foo)

this turns a strict comparison into a different syntax but still strict comparison

  • Changing AssertEqual($scalarType, $sameScalarType) to AssertSame($scalarType, $sameScalarType) wouldn't require strictRulesInstalled

  • Changing AssertEqual($scalarType, $differentScalarType) to AssertSame($scalarType, $differentScalarType) would require strictRulesInstalled since it's not safe

if this is how regular strict-rules comparison work, then it makes sense to me (did not check).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants