-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Simplify returns #2980
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
Simplify returns #2980
Conversation
Should I apply the CS, or there will be a PR just for that? |
} | ||
|
||
return true; | ||
return ! ($index1->isFullfilledBy($index2) && $index2->isFullfilledBy($index1)); |
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 argue this approach is better than the original one. When debugging code, it may be convenient to set a break point on one of the return
s and inspect the scope before switching the context. Especially, when the condition is complex. A better rework could look like:
if ( ! $index1->isFullfilledBy($index2)) {
return true;
}
if ( ! $index2->isFullfilledBy($index1)) {
return true;
}
return false;
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.
May I do this change in another PR? Keeping one proposal per PR? I agree with you, and there are other places that we can change it 😄
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.
It's fine if this change is removed from here and resolved as part of another patch.
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 find this much more readable and simpler to be honest:
return ! $index1->isFullfilledBy($index2) || ! $index2->isFullfilledBy($index1);
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.
@lcobucci that's just De Morgan's law applied (except that @carusogabriel's is the "simplified" version ;-) )
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.
"De Morgan's law"
Learn something new today 😄
} | ||
|
||
return false; | ||
return $this->spansColumns($other->getColumns()) && ($this->isPrimary() || $this->isUnique()) && $this->samePartialIndex($other); |
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.
Same as above, this condition could be split into a series for better readability.
I believe, all tickets marked as "Code Style" should be reflected in the coding standards if technically possible. Otherwise, it will be a never-ending story of writing new code and fixing the style. Also, having it standardized will help make sure all contributors agree with the code style, not only the ones involved in work on a given pull request. |
@morozov Shipping this for now. I think we should get @carusogabriel to propose these in the https://github.com/doctrine/coding-standard once he's joined the party :-) |
No description provided.