[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