PSR-2 coding standard compatibility

[michailw]

Can we change coding standards to be PSR-2 compatible?

[aik099]

Why?

If we even try, then amount of renames to make (considering used sake_case vs camelCase during variable/method parameter naming) would be huge.

[michailw]

I know that you've developed own coding standard tool which is requirement in composer of this library. Anyway I think it would be easier for me as fresh look in this project to sit in front of code which looks familiar to everyone. Also my IDE won't blink so many times :-) That's the purpose of standards, and in PHP world we have defined PSR-2.
You're right about amount, but there are automated tools for that purpose (like PHP CodeSniffer).

[aik099]

PSR-2 might be popular, but fact, that it has too many unknowns (just look at how much confusion there is in https://github.com/squizlabs/PHP_CodeSniffer/issues about how PSR-2 should work if it's not written explicitly in standard itself). For that reason I've developed a standard of my own (see https://github.com/aik099/CodingStandard), that checks way more stuff, that PSR-2 ever will. I've been using it in all projects I've created since then.

I'm proposing to implement aik099/CodingStandard#102 and use resulting standard to auto-fix current repo.

This way we'll meet your requirement for PSR-2 compliance and keep all extra checks in current standard.

[michailw]

I think we missed my initial point. I'm not suggesting to drop aik099/CodingStandard in favour of PSR-2. I want to suggest that aik099/CodingStandard can be PSR-2 compatible instead of changing some of PSR-2 rules which makes both standards incompatible between each other. Does it make sense?

[aik099]

I want to suggest that aik099/CodingStandard can be PSR-2 compatible ...

That's exactly what is about.