[wp-trac] [WordPress Trac] #41057: Update PHP codebase per WordPress PHP Coding Standards

[WordPress Trac]

#41057: Update PHP codebase per WordPress PHP Coding Standards
----------------------------+-----------------------
 Reporter:  netweb          |       Owner:  pento
     Type:  task (blessed)  |      Status:  accepted
 Priority:  normal          |   Milestone:  4.9
Component:  General         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+-----------------------

Comment (by jrf):

 @pento

 > What's the condition for splitting a long array declaration into
 multiple lines? The arrays at the top of admin-ajax.php and class-wp-list-
 table.php are split correctly, but those in class-wp.php are not.

 This currently works as follows:
 * If an array is already multi-line, each item should start on a new line.
 * If an array is single-line, but contains associative keys and more than
 one array item, it will be forced to become multi-line.

 I.e. single line non-associative arrays, like in `class-wp.php`, are left
 as is.

 > The inline XML in xmlrpc.php is currently indented with spaces, at 2
 spaces per level. This isn't being correctly fixed - instead of replacing
 each 2 space indent with a tab, it's replacing groups of 4 spaces with a
 tab. Again, I'm not worried about this - we can manually fix it.

 Sniffs can not determine whether something is ''intentional precision
 alignment'' or ''unintentional incorrect alignment''. This is why this is
 not being fixed.
 The PrecisionAlignment sniff which was merged today should warn about
 this, but will not auto-fix it. See: https://github.com/WordPress-Coding-
 Standards/WordPress-Coding-Standards/pull/1099

 > WP_Admin_Bar::_render_item() probably needs to be rewritten, because
 that kind of abuse of white space collapsing is just not on. Conforming to
 the coding standards breaks the HTML output.

 I agree. Rewriting this method would be the better solution.
 I recall having a conversation with someone about these type of situations
 - multi-line embedded PHP in HTML snippets - before, but can't find the
 link at this moment. The consensus from that conversation was that - if at
 all possible - variables should be created before echo-ing out the HTML
 string when more than simple logic is needed.
 Or alternatively, the whole string should be build up within a PHP block
 and only echo-ed out at the end.

 > Generally, I'm finding everything to be looking good, and much easier to
 read. The bits that are still hard to read are the long lines that we
 don't have a standard for splitting up.

 There is a sniff which can warn about this - `Generic.File.LineLength` -,
 but this cannot be auto-fixed easily as in most cases it will need a human
 eye to decide the best course of action.
 The above mentioned sniff is not in any ruleset at this moment as this is
 not covered in the handbook.
 As per your examples, there may be specific situations in which it can be
 auto-fixed, but that would still not be an easy sniff to create and I
 would expect it will need extensive test-cases to get it right.

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