[wp-trac] [WordPress Trac] #52217: Fix code issues identified by PHPStan

[WordPress Trac]

#52217: Fix code issues identified by PHPStan
-------------------------+-------------------------------
 Reporter:  johnbillion  |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  5.9
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  coding-standards
-------------------------+-------------------------------

Comment (by johnbillion):

 My original proposal was going to be to configure and run PHPStan on core
 (at level 1 or 2) and fix the issues it raises, then circle back at a
 later point to consider whether implementing it as part of our tooling and
 CI would be a good idea. Jorbin and Viktor made positive sounding noises
 in the comments above so I just went with it.

 From my experience with PHPStan at levels 0 and 1, once you get the
 exclusions and configuration in place that you need then it only warns
 about real code problems, and as I mentioned it won't consider anything
 relating to types.

 > How do we help contributors analyze incidents reported by it to
 determine if it's a real and fixable issue and then resolve each?

 I would say the PHPStan error messages are similar in terms of technical
 complexity and language to PHPCS. The errors you'll see from levels 0 and
 1 relate to undefined variables, unknown functions and methods, and
 incorrect parameter counts. I would say these are on par with PHPCS in
 terms of how experienced you need to be to understand and fix the problem.

 PHPStan has a documentation section specifically for writing PHP code
 correctly, for example [https://phpstan.org/writing-php-code/solving-
 undefined-variables solving undefined variables].

 > Do you foresee it becoming a pain point for contributors?

 Potentially yes, but I'm of the opinion that errors from
 [https://phpstan.org/user-guide/rule-levels levels 0 and 1] are manageable
 now the initial configuration is in place. It's not going to report
 anything opinionated, nor is it going to report problems with types.

 From reading through the conversation and PRs on #51423 I think it's
 trying to tackle too much at once and is probably the source of the pain
 points you mention. In that situation I don't think implementing PHPStan
 at the level that reports those problems is realistic, certainly not at
 the moment anyway.

 I'm very happy to fix the actual errors that I've seen at level 1 and then
 open a separate ticket for implementing PHPStan into the tooling, it was
 just easier and more accessible to implement it all together in my PR.

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