Simplify code structure and optimize conditional logic in REST API controllers

[antonvlasenko]

After inspecting the code in the wp-includes/rest-api/ directory, the following minor issues were identified:

• unnecessary local variables;
• static methods called dynamically;
• non-static methods called statically;
• non-optimal order of conditional expressions in if statements, impacting performance;
• inefficient usage of ternary operators;
• unconsolidated isset() and unset() statements;
• redundant else-if statements;
• use of count() to check for empty arrays, impacting performance;

and other related issues.

This ticket is supposed to track patches intended to address these issues.

Trac ticket: https://core.trac.wordpress.org/ticket/62333

Trac ticket: https://core.trac.wordpress.org/ticket/62333

Trac ticket: https://core.trac.wordpress.org/ticket/62333

Trac ticket: https://core.trac.wordpress.org/ticket/62333

Trac ticket: https://core.trac.wordpress.org/ticket/62333

[adamsilverstein]

Hey @antonvlasenko =- thanks for opening the ticket and PRs.

I'm curious what led you to these refactoring points, are you using a tool to identify these fixes?

Is there some issue you are trying to address / what is your goal with these changes - better compatibility or tooling, or ?

In general, we shy away from refactoring for refactoring's sake in core, see ​https://make.wordpress.org/core/handbook/contribute/code-refactoring/

Have you check the performance number before/after?

[antonvlasenko]

Hi @adamsilverstein,
Thank you for your comment.

There were several goals with these PRs:

• making small performance tweaks;
• making the code stricter, leaving less room for errors;
• fixing some obvious issues, like calling non-static methods statically;

The intention was to make the code stricter and more static-analysis-friendly, as this would help catch more bugs and inaccuracies down the road.

Have you check the performance number before/after?

@mukeshpanchal27 I measured the performance improvement after you asked this question.
For example, in the widget controller, the improvement is about 0.6-1.5 microseconds per widget (of course, if certain conditions are met, and it depends greatly on the particular system).
The difference is measureable but minimal.
I expect similar results when measuring other controllers.

[mukesh27]

This ticket was discussed during the Performance bug scrub.

The PRs need a review from the REST API component maintainers.

cc. @timothyblynjacobs @kadamwhite @spacedmonkey

Additional props to @joemcgill.