[wp-trac] [WordPress Trac] #63268: PHPStan code quality improvements for 6.9

WordPress Trac noreply at wordpress.org
Thu Sep 18 15:16:59 UTC 2025


#63268: PHPStan code quality improvements for 6.9
----------------------------+-------------------------------
 Reporter:  justlevine      |       Owner:  SergeyBiryukov
     Type:  task (blessed)  |      Status:  accepted
 Priority:  normal          |   Milestone:  6.9
Component:  General         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  coding-standards
----------------------------+-------------------------------

Comment (by justlevine):

 @SirLouen the original intention for this ticket was specifically to
 remediate PHPStan violations, in order to reduce the friction (via
 errors/baselines) needed to adopt PHPStan
 (https://core.trac.wordpress.org/ticket/61175), as well as track progress
 and the impact of using that tool to bolster the justifications in favor
 of adopting it.

 As a contributor and **not** a committer, I'd love for there to *also* be
 "Code Quality" catch-all (versus a ticket to explicitly justify each
 change) that may anecdotally remove errors from the PHPStan baseline, but
 I'm hesitant to repurpose this one.

 IMO "Code Quality" is a very subjective term if it's not tied to a
 specific tool. This ticket is AFAIK what's enabling @SergeyBiryukov ,
 @johnbillion , et. al. to review and make iterative progress without
 needing to spend additional time/cognitive energy on triage. ("No
 unnecessary refactors" still applies, but since we're starting from a
 clear and defined list the scope of potential changes is limited. Nobody's
 gonna randomly go Liskoff or unnecessarily OOP a bunch of legacy code).
 Ultimately, I defer to both of them and whatever makes things easiest for
 them 🙇

 > I know that PHPCS is also technically an Static Analysis tool, but we
 already have a Code Standards improvements for X.Y.

 To be unnecessarily pedantic, PHPCS is a _linting_ tool and not static
 analysis 😅 but still I think there too, it's the virtue of it being a
 tool with a specific ruleset + violation list that allows for relatively
 efficient triage.

  - "Is PHPCS complaining?" > "Do we care that PHPCS is complaining?" >
 "**How much** do we care that PHPCS is complaining vs the effort/cost of a
 refactor"
 is a lot easier than
 - "is this subjective code pattern measurably better than that also
 subjective one?"

 > I think users will find it easier to write here than if this is
 exclusively dedicated to anything that comes from PHPStan specifically.

 I would love to see other contributors take the
 [https://github.com/WordPress/wordpress-develop/pull/7619/files#diff-
 6275e0d1d144cdbf30ef77cdca0d8d4c6a9a6f1f2cf2b9d87c63b791910667c9 | PHPStan
 baseline] and start triaging/patching with me.

 That baseline is the perfect list of `good first issues`: small, scoped,
 requiring minimal if any new Unit tests. Just need enough know-how to know
 what's "worth doing" and what's testing noise (e.g. the PHPCS equivalent
 of an invalid comment end char vs not sanitizing a var).

 But maybe I'm being too optimistic?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63268#comment:180>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list