[buddypress-trac] [BuddyPress Trac] #7228: Add PHPCS

buddypress-trac noreply at wordpress.org
Mon Mar 8 11:56:46 UTC 2021

#7228: Add PHPCS
 Reporter:  DJPaul            |       Owner:  (none)
     Type:  enhancement       |      Status:  reopened
 Priority:  normal            |   Milestone:  8.0.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |

Comment (by espellcaste):

 Thanks John! Your feedback is not discouraging at all, on the contrary. I
 have a different take and goal about PHPCS for BuddyPress.

 I see PHPCS not as a ''valueless'' standard, but as an opportunity to
 catch bugs, or at the very least, to be aware of them and create a plan to
 fix them. In the long run, we will be making them visible and hopefully
 fixing them. This is also a good opportunity to set, or follow, some good
 patterns and standards across the projects.

 Some of your concerns I'm not sure we can solve. IDE setup, for example,
 is very tricky and personal. BuddyPress can't, nor should, be responsible
 or be concerned with that. Like you said, this should be for each person
 for figure it out.

 > ... the codebase ends up littered with ugly exception comments anyways –
 the antithesis of cleaner code.

 Another good point. I believe that's inevitable with a project with such a
 history as BuddyPress. But I'd caution here that the goal is not
 perfection or following the ''valueless'' standard by the book. But to
 thrive for a better code base, and at the very least, catch ERRORS as soon
 as possible.

 Will we silent or remove some rules? Yes. But ideally, they would be
 warnings, not errors. But the most important point I could make here is:
 we need to know where the problem lies. Today, only checking against
 `PHPCompatibilityWP`, we can't.

 > It needs to be up to committers to run PHPCS when committing, and
 patches shouldn't be rejected only because of PHPCS issues.

 I disagree here partly. I think that patches, or commits in Github
 projects, should not go through if they have errors in their code. They
 can have warnings, but not errors.

 We can run phpcs: checking for errors, in changed files only. And run it
 completely in the CI. We can also see warnings in the CI and in the
 terminal but not fail the build/commit/release/etc.

 Again, the goal here is to be proactive and catch errors early. They might
 be annoying but they are necessary for a better code base. This is not
 only about following rules or standards.


 Overall, I don't see this as disruptive as you seem to be. Ideally, people
 will continue to contribute code as they always have been. They might only
 be bothered if they have an error in their code, something I presume to be
 a good thing to catch beforehand.

 My proposal is the creation of a custom BuddyPress ruleset with packages
 and rules that should be shared between the BuddyPress projects (including
 BP itself).

 The projects themselves can exclude or add custom rules as needed or
 desired. But currently everyone is doing or installing their own thing.

 The BP REST API uses a strict WordPress ruleset catching all errors, but
 BuddyPress doesn't. The BP WP-CLI package does their thing, etc. I mean,
 everyone is doing something differently. Having a common standard should
 improve overall code quality by following sensible rules.

 Sharing future changes across the projects will be easier as well with
 every project using this custom package/ruleset.

 Overall, I think BuddyPress would benefit from it. In the same way we
 encourage unit tests as much as possible, we should be encouraging
 following PHPCS as well.


Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7228#comment:16>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list