php
php copied to clipboard
Automated formatting for PHP code files
Looking for input. Not disagreeing with people having a personal preference of one style over the other, but what do you think of implementing some sort of automated formatting that can be used to consistently (and automatically) apply a style to the code base? We can then also implement CI to lint against this.
Some potential solutions:
- prettier-php (https://github.com/prettier/plugin-php) -- not sure how I feel about having to add yarn as a dependency in a php repo
- php-cs-fixer (https://github.com/FriendsOfPHP/PHP-CS-Fixer)
- phpfmt (https://github.com/kodeclan/phpfmt)
Thoughts? Opinions?
@arueckauer @petemcfarlane @dstockto
That's a good idea, it's common practice nowadays and very helpful to have a tool taking care of it.
I think the two most commonly used linters are PHP-CS-Fixer and PHP_CodeSniffer. I have never used prettier for PHP code and not heared of phpfmt (which seems not highly maintained).
There is the Extended Coding Style by the PHP-FIG specifying some basic formatting. Then there are coding standard from various projects like Doctrine and Laminas which provide a (more) complete ruleset. Both are extendable to personal preferences.
I have worked with both PHP-CS-Fixer and PHP_CodeSniffer and either would be a good fit for this codebase. For my projects I use the Laminas Coding Standard with a slight adjustment and am very happy with it.
I remember @dstockto and I discussed and agreed on some rules a while back, but it never went that far, that these rules were enforced. This project has some configuration for PHP-CS-Fixer. We could either build on that or use something else. A good way to start would be to agree on one standard and then aggree and add additional rules as necessary.
Yea, I have no experience with things other than php-cs-fixer, but just wanted to put out there that open to alternatives if better things exist. If was have a start with php cs fixer, building on that might be an easy win to implement this.
Sounds good, I’ve used php-cs-fixer and php CodeSniffer - both on the same project at times, although I wouldn’t recommend this because in edge cases they sometimes contradict each other and cause more headaches. Whichever standard I recommend it a superset of PSR12.
On 28 Sep 2021, at 04:34, Tim Austin @.***> wrote:
Yea, I have no experience with things other than php-cs-fixer, but just wanted to put out there that open to alternatives if better things exist. If was have a start with php cs fixer, building on that might be an easy win to implement this.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Since we have phpcs in our CI already, I spun up a draft pr with the laminas coding standard rules added. Quite a few rules I think we would have to disable (some just due to project requirements -- e.g. the example solution being named different from the inner class). But was super simple.
Draft PR here: #421
@arueckauer you had mentioned that you personally disable some rules for your own work? which ones?
@neenjaw Awesome!
Gobally I exclude the PSR1.Methods.CamelCapsMethodName
rule for test classes. Descriptive test method names can be rather long and I write them in snake_case for improved readability. Other than I only add exclusions for legacy code, where the coding standard can not be applied all at once.
As for this project, there are quite a few errors that could be fixed automatically. While it is possible to ignore or disable phpcs for specific lines in a file, I would suggest having all these rules in the phpcs configuration file thus not confusing users with irrelevant coding style directives.
Came here from #412 I'd like to offer a 👍 to that effort. Not sure about enforcing the single vs double quotes as that has always seems a tad myopic to me, but the trailing comma helps maintain a clear source of who made which changes and allows simpler line-based ownership of community efforts.
I also made a comment on #421 that perhaps adding professional coding standards and ones outside of core PSR might distract learners with opinion. I Understand PSR's are sort-of opinion-based, but they seem the closest thing to a universal basis for PHP to me.
PSR-12 is already conigured (see phpcs-php.xml). Since the PSR-12 is providing "only" very basic rules. This discussion is about having a bit more precise standard.
I also made a comment on #421 that perhaps adding professional coding standards and ones outside of core PSR might distract learners with opinion. I Understand PSR's are sort-of opinion-based, but they seem the closest thing to a universal basis for PHP to me.
These standards only apply to code in the repo, not student supplied code. We don't lint submitted code in any way at present according to psr standards or otherwise. One motivation to develop these repo standards is to guide PR submissions for exercise updates and future concept exercise development.
It looks like this issue is solved with:
- https://github.com/exercism/php/blob/main/.github/workflows/exercise-lint-phpcs-psr-12.yml
- https://github.com/exercism/php/blob/main/phpcs-php.xml
@neenjaw Should it be closed ?
It looks like this issue is solved with:
https://github.com/exercism/php/blob/main/.github/workflows/exercise-lint-phpcs-psr-12.yml
https://github.com/exercism/php/blob/main/phpcs-php.xml
@neenjaw Should it be closed ?
As @arueckauer said above:
https://github.com/exercism/php/issues/418#issuecomment-952792656
This issue has not been fulfilled by the existing psr12 linting standard.
However since I haven't continued with this and no one else has, we can close it.
Oh sorry I did not read this comment. To me we should stick to PSR12 for as this is the only widely accepted coding standard.
Personally I like https://github.com/doctrine/coding-standard (with some tweaks)