Improve coding style consistency

[IanDelMar]

• Remove duplicate ignore statement for SlevomatCodingStandard.Functions.UnusedParameter.UnusedParameter.
• Add @see tags to all return type extensions.
• Replace in_array with strict comparison when only one function is supported.
• Replace 'Class' with Class::class in new ObjectType().
• Sort use statements alphabetically.

[szepeviktor]

Thanks.

Could you import WP_Error when there is a backslash? \WP_Error

[IanDelMar]

I imported WP_Error, but test:cs:fix "fixes" this by removing the import and adding a backslash. I believe this is due to the Slevomat rule enforcing fully qualified exceptions. To use imports, you would need to add WP_Error to ignoredNames. However, I didn't want to mess around with your coding standard. By the way, are you planning to update it to work with PHP 8.1+?

[szepeviktor]

By the way, are you planning to update it to work with PHP 8.1+?

How to do that? BTW The WP ecosystem still runs on 7.4 https://wordpress.org/about/stats/#php_versions

[herndlm]

I think the last time I looked here or in the stubs, your coding standard repo or one of its dependencies was the blocker to go higher with PHP in the workflow/pipeline.

I'm using WordPress with 8.3 btw 😊

[szepeviktor]

Let's think about PHP 8 support after core supports it. https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/

[IanDelMar]

How to do that?

Replace the rules from the Neutron standard. I believe they are causing the incompatibility with PHP 8.1+. These rules are abandoned and will not be updated anyways.

BTW The WP ecosystem still runs on 7.4 https://wordpress.org/about/stats/#php_versions

This is not about the WP ecosystem but about contributors to this repository who must switch between PHP versions just to run the code sniffer due to incompatible rules. I don't see any valid argument for using the PHP version supported by the core as the benchmark for the development tools in this repository. However, it's ultimately your decision, and I don't want to be pushy, especially since you are the one who has to do the update work.

[szepeviktor]

All right, I fix it. What is the concrete problem with Neutron? https://github.com/szepeviktor/phpcs-neutron-standard/blob/623a2d03bd942637752417370bdc73b64189c77f/composer.json#L41

[szepeviktor]

php8.1 vendor/bin/phpcs

I get no errors.

[IanDelMar]

 1 | ERROR | An error occurred during processing; checking has been aborted.
   |       | The error message was: trim(): Passing null to parameter #1
   |       | ($string) of type string is deprecated in
   |       | phpstan-wordpress/vendor/wp-coding-standards/wpcs/WordPress/Sniffs/WP/I18nSniff.php
   |       | on line 194
   |       | The error originated in the WordPress.WP.I18n sniff on line 194.

And you can't update WPCS because Neutron requires it. Or something like that. It's been a while since I looked at this and can't remember exactly. It's great that you are considering updating your standard!

Maybe it wasn't Neutron at all, but WPCS. I'm sorry, I just can't remember.

[szepeviktor]

It turns out it is about upgrading WPCS to v3.

[szepeviktor]

@IanDelMar Here you go. v1 is released with WPCS v3.

[szepeviktor]

@IanDelMar What phpstan min. version does not produce these errors? https://app.travis-ci.com/github/szepeviktor/phpstan-wordpress/jobs/623506447

[IanDelMar]

@IanDelMar What phpstan min. version does not produce these errors? https://app.travis-ci.com/github/szepeviktor/phpstan-wordpress/jobs/623506447

Started to check that, stopped at 1.10.60 and did not continue. But will check now.

[IanDelMar]

@szepeviktor Starting with version 1.11.0, no more errors.