PHP-CS-Fixer setup #277
PHP-CS-Fixer setup #277
Conversation
e6e2a6e to
4e3ddcf
Compare
136afcf to
8ee3e6f
Compare
There was a problem hiding this comment.
Thanks @uuf6429 mostly I think the tool setup and changes are OK, with a couple of comments / questions.
There are also some places where the automated fix highlights an opportunity to make a further manual improvement - I would suggest we do those in this branch (but committed separately either at the start or end of the branch) while we can see them?
|
|
||
| namespace Behat\Gherkin\Exception; | ||
|
|
||
| use RuntimeException; |
There was a problem hiding this comment.
What rule/ruleset does this come from? Personally, I prefer to have use statements for all classes including built-ins.
There was a problem hiding this comment.
I guess that's the global_namespace_import rule, from the Symfony ruleset.
I don't mind it either way - but it would be good to hear other opinions, perhaps?
There was a problem hiding this comment.
it is indeed this rule.
I'm fine with either configuration for this rule (either always importing or never importing for the global namespace), but the project should be consistent (and currently, I think a lot more code follows the Symfony rule, so changing that should probably be done in a separate PR)
There was a problem hiding this comment.
I imagine we'll eventually want Behat/Behat to be consistent with this decision too - @carlos-granados @ttomdewit do you have a preference?
If we do decide to configure it to import everything, I guess we should just disable the rule in this PR rather than change these ones and then change them back.
There was a problem hiding this comment.
My personal preference is to import everything, it makes the code less cluttered
There was a problem hiding this comment.
@uuf6429 I make that 2 in favour of import everything, 2 fine either way. I suggest disabling the rule in this PR and reverting the changes it produced, then adding a separate PR to add it (and @ttomdewit can feed into that if he feels strongly about it)?
|
@uuf6429 I think it should work if you do an interactive rebase, stop to edit the commit with the automatic changes and disable the rule/re-run it there, then continue the rebase? There may be a small number of conflicts with manual changes added subsequently to resolve as the rebase continues but probably quicker/safer than reverting them manually (and better for code history)? |
This comment was marked as resolved.
This comment was marked as resolved.
287c946 to
8f204ff
Compare
|
Tests look good. Commits should be even clearer now. |
|
@uuf6429 when we discussed about adding a CS tool in the main Behat repo, we said that we should probably include a |
|
Done. Please keep in mind that this PR can no longer be squashed and a rebase will require updating the newly added ignore file. |
Based on #275.
I tried to find the best-matching set of rules for the project and in the end went with PER-CS + Symfony + minor-adjustments.
In my opinion, there are still some silly/redundant things, such as aligning PHPDoc contents or the file header, but at least this PR fixes any inconsistencies. Let me know if we should actually revise any existing code style.