search

squizlabs / PHP_CodeSniffer

PHP_CodeSniffer tokenizes PHP files and detects violations of a defined set of coding standards.
BSD 3-Clause "New" or "Revised" License
10.66k stars 1.48k forks source link

Stop changing the PSR-2 code style #1004

Closed malkusch closed 8 years ago

malkusch commented 8 years ago

It's really annoying seeing constantly unchanged builds failing just because PHP_CodeSniffer changed some whitespaces rules, again.

aik099 commented 8 years ago

They were changed for a reason. A bugfix most likely.

malkusch commented 8 years ago

It's not the first time that this happens. I noticed this already a long time ago and this happens frequently. Can't you just stop doing that and consider PSR-2 as a stable thing.

aik099 commented 8 years ago

It's developers who actually report these things as inconsistent and aggressively prove that it must work this way, even if PSR-2 isn't telling anything about that specifically.

@gsherwood just changes code to make them happy. For that reason (too many unanswered questions) I don't use PSR-2 at all.

gsherwood commented 8 years ago

Can't you just stop doing that and consider PSR-2 as a stable thing.

If there are bugs, such as parts of PSR-2 that are not currently checked, or errors that should not be included in PSR-2, I fix them. The latest one you've come here to complain about was a part of the PSR-2 standard that PHPCS wasn't checking. Now it does. That's actually a good thing.

malkusch commented 8 years ago

What is the market share of phpcs? If it's above 99% I would say the implementation of phpcs is the defacto standard. Changing the interpretation in phpcs has much more impact than changing the PSR itself.

gsherwood commented 8 years ago

Changing the interpretation in phpcs has much more impact than changing the PSR itself.

The implementation of PSR-2 in PHPCS only changes when someone tells me about a problem. These are bug fixes that are being applied. i.e., they are ways in which PHPCS is not correctly enforcing PSR-2. This clearly wouldn't happen if I wrote perfect code to begin with. But I didn't. So it happens.

So even if everyone agrees that PSR-2 is rubbish and part of it should change, there is no way I could actually make that change and still call the PHPCS implementation a "PSR-2 implementation".

But there are a lot of areas where PSR-2 is ambiguous, or uses embedded example code snippets in place of actual words (a shortcut, but not ultimately helpful in a debate), or does things like say whitespace is not part of the standard but clearly points out whitespace standards in places. Those things cause confusion and debate.

Ultimately, I don't want to decide that debate and so I ask for it to be resolved by the PHP-FIG voting members on the mailing list. They typically show little interest, and so most things go unresolved. The result is that my interpretation (the one I made when initially writing the standard and asking for approval on the mailing list) is the one that stays in the product. Given it is always a debated point, that always upsets someone.

There really isn't anything I can do about that. If I change the standard, someone complains. If I don't, people come and +1 the bug report that I've closed. "The only winning move is not to play."