[wp-trac] [WordPress Trac] #55635: wp_convert_hr_to_bytes() report correct byte sizes for php.ini "shorthand" values

[WordPress Trac]

#55635: wp_convert_hr_to_bytes() report correct byte sizes for php.ini "shorthand"
values
-------------------------------------------------+-------------------------
 Reporter:  dmsnell                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Upload                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests has-patch dev-      |     Focuses:
  feedback changes-requested                     |
-------------------------------------------------+-------------------------

Comment (by costdev):

 > there are examples in that linked docs standard to single-line docblock
 comments, so maybe I will undo my change that turned them into multi-line
 statements. that is, unless some tool is simply unaware of the guideline
 and naively replaces all single-line comments it sees into //. can you
 confirm if it's happening automatically or will it be okay if I move back
 from multi-line to single-line?

 - I'm not seeing any instance of a single line `/** @var ... */` comment
 in the docs standards. Translator comments are a different context, as are
 the docblocks for requires/includes.
 - The change from `/** @var ... */` to `//` is not automatic.
 - You can change the line back to `/** @var ... */` format without a tool
 converting it to something else.

 Thanks for taking a closer look at the plugin results!

 > I'll play around some with it. I'd ideally like to avoid solutions we
 know are adding unnecessary overhead just for the looks of the code (such
 as dynamically building the array or calling a function to get the value).
 I want this code to be lean since it's a fundamental-level operation, but
 at the same time we're not parsing these numbers frequently and hopefully
 this is never representative of the hot path, so some tradeoff in
 performance for readability is probably fine.

 Per my previous comment, I suggest that we don't sacrifice performance due
 to disagreement with a rule in the coding standard, and instead either
 meet the coding standard, or ignore the rule if consensus moves in that
 direction.

 However, IMO, all patches should meet the coding standard, and if
 exceptions are to be made, they should be made about a near-final patch.
 Otherwise we'd have a significant increase in the number of `phpcs:ignore`
 comments in Core. As this ticket still has a number of steps to go
 through, including looking at two different proposed solutions, I think we
 should focus on these first.

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