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

Introduce PHP CS to improve code quality #16755

Merged
merged 5 commits into from Jan 15, 2021
Merged

Introduce PHP CS to improve code quality #16755

merged 5 commits into from Jan 15, 2021

Conversation

sgiehl
Copy link
Member

@sgiehl sgiehl commented Nov 19, 2020

Description:

In order to improve our code quality a bit, it would imho be awesome by stating to introduce automatic PHPCS checks.
I've started with a very basic ruleset, that only disallows the usage of short open tags and forces using \n as line endings.

There is also a new workflow, that will automatically run for Pull Requests, so it can be directly seen if a PR breaks any coding rules.

If that PR get's merged I would add some other rules step by step and directly provide fixes for code that doesn't comply. Maybe anyone else also has some suggestions for rules we should use.

Review

  • Functional review done
  • Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
  • Security review done see checklist
  • Code review done
  • Tests were added if useful/possible
  • Reviewed for breaking changes
  • Developer changelog updated if needed
  • Documentation added if needed
  • Existing documentation updated if needed

@sgiehl sgiehl added the RFC Indicates the issue is a request for comments where the author is looking for feedback. label Nov 19, 2020
@sgiehl
Copy link
Member Author

sgiehl commented Nov 19, 2020

I've added another commit that adds a short open tag (should be removed before merge). The check fails now because of it. The error is also directly highlighted in the changed files tab.

@tsteur
Copy link
Member

tsteur commented Nov 19, 2020

sure could start with just this and see over time if/when we run into issues that could have been detected through this and then add it when needed (or when we notice something as part of a review we could think whether we can automatically detect certain thing in the future). Generally not so much coding style as it's not as important but probably more like not using unserialize method directly checks etc.

@sgiehl
Copy link
Member Author

sgiehl commented Nov 20, 2020

Disallowing some methods like eval or create_function seems also be good. Will add a simply rule for that and for forcing to use Common::safe_unserialize instead of unserialize. Any other method we should disallow?

@tsteur
Copy link
Member

tsteur commented Nov 22, 2020

Any other method we should disallow?

Not needed for now. Be good to keep it simple.

@sgiehl sgiehl force-pushed the phpcs branch 2 times, most recently from 5dd04f7 to b9b1b4b Compare November 23, 2020 10:04
@sgiehl sgiehl added this to the 4.1.0 milestone Nov 24, 2020
@sgiehl sgiehl added Needs Review PRs that need a code review and removed RFC Indicates the issue is a request for comments where the author is looking for feedback. labels Dec 14, 2020
@mattab mattab modified the milestones: 4.1.0, 4.2.0 Dec 21, 2020
@sgiehl
Copy link
Member Author

sgiehl commented Jan 14, 2021

@tsteur @diosmosis can we merge this one? Might be helpful to have some basic checks and being able to add new checks if something pops up in the future that would have been detectable with phpcs...

@sgiehl sgiehl requested a review from diosmosis January 14, 2021 10:42
@tsteur
Copy link
Member

tsteur commented Jan 14, 2021

👍

@sgiehl sgiehl merged commit b38578b into 4.x-dev Jan 15, 2021
@sgiehl sgiehl deleted the phpcs branch January 15, 2021 07:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Review PRs that need a code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants