Suggestion for keeping an consistent, automatic code style (with php-cs-fixer) - #92
Suggestion for keeping an consistent, automatic code style (with php-cs-fixer)#92pscheit wants to merge 4 commits into
Conversation
| $mismatchDescription->appendText('element ')->appendValue($k) | ||
| ->appendText(' was ')->appendValue($actual[$k]); | ||
| ->appendText(' was ')->appendValue($actual[$k]) | ||
| ; |
There was a problem hiding this comment.
I would probably write it more like:
$mismatchDescription
->appendText('element ')
->appendValue($k)
->appendText(' was ')
->appendValue($actual[$k])
;
| $description | ||
| ->appendText('array with key ') | ||
| ->appendDescriptionOf($this->_keyMatcher) | ||
| ; | ||
| ->appendText('array with key ') | ||
| ->appendDescriptionOf($this->_keyMatcher) | ||
| ; |
There was a problem hiding this comment.
this looks more concise to me!
| $mismatchDescription->appendText('array was ') | ||
| ->appendText('[') | ||
| ; | ||
| ->appendText('[') | ||
| ; |
There was a problem hiding this comment.
$mismatchDescription
->appendText('array was ')
->appendText('[')
;
| * @param mixed $item the object against which the matcher is evaluated. | ||
| * | ||
| * @return boolean <code>true</code> if <var>$item</var> matches, | ||
| * @return bool <code>true</code> if <var>$item</var> matches, |
There was a problem hiding this comment.
up for discussion of course, i like it more if its concise (but dont care if its boolean or bool)
|
|
||
| public function testMatchesArrayContainingKey() | ||
| { | ||
| $array = array('a'=>1, 'b'=>2, 'c'=>3); |
There was a problem hiding this comment.
thought about this a lot, but actually Hamcrest itself describes array's with => (with whitespace around the operator) and this is PSR- standard, so would change that
| { | ||
| assertThat((float) 5.2, floatValue()); | ||
| assertThat((double) 5.3, doubleValue()); | ||
| assertThat((float) 5.3, doubleValue()); |
There was a problem hiding this comment.
There is no difference in PHP. float, double or real are the same datatype.
At the C level, everything is stored as a double.
There was a problem hiding this comment.
But 'double' is going to be deprecated in PHP 8.6.
|
@pscheit , please rebase, because there are merge conflicts right now, that would block any further merge attempts. |
|
hey @aik099 i would just close this. This was over a year without any interest, so it does not matter enough for this project i think. This was just a suggestion and it's fine that this isnt a priority. |
|
That's life, I guess. Sometimes maintainers have time to maintain the project, sometimes they don't. People do have families and work that also requires their attention. Always glad to see new people, like you, coming in and using open source projects. It would be really cool if people using projects actually reported back, so it's visible how many people are interested in keeping the project alive. But I guess GitHub doesn't yet have an API for that 😄 . |
|
yeah i get it. It was not a comment directed to maintainers, more to generally everyone looking into this repo could have reviewed that and maybe pushed one thing or another forward. I do have families and a lot of other responsibilities, so happy if someone takes this over, but if not I wouldnt hold a grudge. I just don't want to pursue it. |
3 participants
I noticed a few comments about Codestyle in PRs.
To keep maintainer and contributors happy, I'd suggest to automate the codestyle. That way everyone can concentrate on the code(quality) and not on the codestyle.
Of course a code-formatter does not everything 1000% the way one wants. It's just not customizable entirely.
However this leads to a more consistent codestyle (thats why PSR-x was born) throughout different projects - which I think is a good thing.
Used:
https://cs.symfony.com/doc/usage.html
Cause I feel like this has become a defactor-standard.
Based it on PSR-12, but a lot needs customization.
Non "standard" are in this repo:
Anyway, this is just a suggestion, happy to adjust whatever you want (and we can).
Would probably add this to the pipeline, because otherwise no one runs this, and WHEN someone runs it and wants to contribute everything would be outdated.
Of course we can disable the method chaining rules and leave it in "free"-mode as is right now.
Hope you like it!