Discussion: Migration to a offline code checker or better not?

[christianlupus]

In #1048 the discussion started, if it was somehow possible to check the code style offline. This would speed up the development process: in case of online checks, the potential error-prone code needs to be checked in, causing errors by StyleCI. Then a refactor cycle can be done and the corrected code (force-) pushed.
All in all not best from the perspective of potential contributors.

I tried out the PHP_CodeSniffer as suggested in the comments of the named PR. It reports a bunch of errors in the psr1 mode. The other modes report hundreds of issues. I think those in the psr1 mode can be solved quite simply.

However, I am unsure if this is sufficient to make StyleCI happy in the long run. A short test revealed, that some changes @dromer made to fix StyleCI need to be reversed again as phpcs's styles seem to enforce the contrary.
Example: Appending strings in PHP. StyleCI seems (from the commits) to require no blanks between period and text: 'Some Text'.$var. The styles psr2 and psr12 require 'Some Text' . $var.

I think it should be in general decided, how we want to proceed. An offline test simplifies working much. I have seen this during the development of e.g. #1088. Lots of commits mainly to make Travis and the GitHub actions happy as this is the only way to trigger builds/checks online. Inserting the phpcs checker in Travis should be straight forward. So we could do the following:

1. Stick with StyleCI. This has the drawback that future development will always require push-modify-repush development cycles.
2. Migrate to PHP style checker. This makes @dromer's work partly redundant as it needs refactored and the new checker installed in the test scripts.

I think it is true that we should stick with one tool here. Using multiple tools with contradicting requirements will cause a lot of headaches.

Therefore I put this here for discussion. I hope for a fluent and friendly discussion.

[Gasman2014]

I am not really the best person to comment - I only identified that PHP_CodeSniffer existed and it looked as though it might be able to address the styling issues that had previously been identified.
I have never used it nor have I done any meaningful PHP development. I agree that a workflow which causes least friction for likely contributors makes most sense with two major considerations.

1. How to get this project back on track as quickly as possible.
2. How to avoid baking in longer term support issues

[vmw]

It doesn't seem like this project is actively mantained, at least not for releases. I'd suggest maybe going easier for the style checker, or picking something that works offline so that people can actually commit sane code.

[dromer]

If anyone has a good suggestion for offline code-checking of PHP I'm all ears!

[vmw]

One practical response might be to waive style-checking for the time being? Or make a subjective call on this? There are a number of bug fixes or commits that could otherwise be merged, but aren't because of this.