Fixed many small phpcs issues #1228
Conversation
|
Hello, thank you for creating this pull request. I have automatically opened an issue http://www.doctrine-project.org/jira/browse/DDC-3458 We use Jira to track the state of pull requests and the versions they got |
|
This one has to stay on hold until the other relevant PRs (for 2.5) are merged. |
|
Ok @Ocramius, just ping when we it's ready to be merged and pr needs rebase! |
| @@ -570,8 +570,8 @@ public function close() | |||
| */ | |||
| public function persist($entity) | |||
| { | |||
| if ( ! is_object($entity)) { | |||
| throw ORMInvalidArgumentException::invalidObject('EntityManager#persist()' , $entity); | |||
| if (!is_object($entity)) { | |||
There was a problem hiding this comment.
Doctrine uses spaces around the negation operator currently (I would vote in favor of changing this to match the PSR-2 rule though, but it is not done currently, and I'm not the one taking this decision)
There was a problem hiding this comment.
Oh didn't know about that code convention @stof! Reverted those changes, but that's indeed something we should try to get according the PSR-2 standards in the future!
There was a problem hiding this comment.
@acrobat we're actually going to keep the ! convention also in future ;-)
There was a problem hiding this comment.
@Ocramius any reason why doctrine differs from the PSR-2? Of course if there is an other reason than personal taste ;)
There was a problem hiding this comment.
PSR-2 is a generic coding standard that is a fit for pretty much everyone: doctrine is much stricter
There was a problem hiding this comment.
@Ocramius Having stricter rules does not forbid us to change these rules to be consistent with PSR-2. The Doctrine CS would then be PSR-2 + Doctrine-specific rules. Currently, it is PSR-2 - negation formatting + Doctrine-specific rules.
For instance, Symfony also applies more rules than PSR-2 (rules which are common to the Doctrine CS for many of them btw), but it builds on top of PSR-2, and we tweaked the Symfony rules a bit when PSR-2 came out to avoid inconsistencies.
There was a problem hiding this comment.
Yes, but we explicitly want to break compatibility with PSR-2 here, that's what I meant.
I am aware that it is not a superset.
There was a problem hiding this comment.
My question is "why do we want to break compatibility here ?". But anyway, this should be discussed elsewhere
There was a problem hiding this comment.
Always the same discussion ;) Maybe it's time to open an issue @ https://github.com/doctrine/coding-standard and have it be settled by the team once and for all.
There was a problem hiding this comment.
@stof we've been doing it for ages and it has worked out really nice so far, so: why not? :-)
We do it for visibility of the negation, fwiw.
acrobat
force-pushed
the
phpcs-fixes
branch
2 times, most recently
from
7c2e3b8
to
73a76cf
Compare
|
This shall be ready now, since 2.5 is out |
|
I rebased the branch, should be good to merge! |
|
@acrobat I rebased and applied this to |
This pr fixes many small phpcs issues