-
Notifications
You must be signed in to change notification settings - Fork 48
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
Conversation
I don't think we should do this here. It'd only make sense when combined with strict-rules. |
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? |
We could do it similarly to deprecationRulesInstalled parameter which is used here I think. |
I think it should be good to go now |
rules.neon
Outdated
- | ||
class: PHPStan\Rules\PHPUnit\AssertEqualsIsDiscouragedRule | ||
arguments: | ||
strictRulesInstalled: %strictRulesInstalled% |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
Thank you. |
Hi @staabm, just saw this new rules. I feel like it should be stricter. It's like if we were reporting Enforcing a stricter comparison, like |
the goal of this PRs rule is about reporting assertions which can use strict-comparison without risk (unnecessary loose comparision).
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) |
I understood that, but then it doesn't require to be behind the There is already rules asking to change things like
All these changes are safe. And not behind the I would think that
The same way |
this turns a strict comparison into a different syntax but still strict comparison
if this is how regular strict-rules comparison work, then it makes sense to me (did not check). |
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