Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expand Coding Standard Tutorial to show how to write a fixer for a sniff #603

Open
rodrigoprimo opened this issue Aug 29, 2024 · 1 comment

Comments

@rodrigoprimo
Copy link
Contributor

The Coding Standard Tutorial page, among other things, teaches sniff developers how to create a sniff. I would like to suggest that we expand this section of the page to show how to create a sniff that can fix the violations automatically.

IMO, the sniff used as an example on that page, DisallowHashCommentsSniff.php, could be expanded to include the fixer code. I would also suggest a separate section detailing the main methods to use when creating a fixer.

If this is approved, I can work on this change to the documentation, but only in a few weeks from now. I don't mind if someone else claims this issue. I will make sure to leave a comment here when I start working on it.

@jrfnl
Copy link
Member

jrfnl commented Aug 30, 2024

Happy to accept such additions.

Text for this can be posted in a comment here (as the wiki is not publicly editable) and added to the wiki by an editor once reviewed and approved.

I would also suggest a separate section detailing the main methods to use when creating a fixer.

Regarding the methods available: when I first started working with the fixer, I used the phpDoc generated docs published on the PEAR website as a reference: https://pear.php.net/package/PHP_CodeSniffer/docs/3.5.2/apidoc/PHP_CodeSniffer/Fixer.html
Those haven't been updated for a while (and the generation for the last dozen versions released via PEAR was broken already), but not that much has changed in the Fixer class, so the info there should still be a good basis for the method reference.

Mind: while the methods are all public, some of them probably shouldn't have been and are intended only for internal use, so I don't think all methods need to be documented, only the typical public API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants