Property and method modifier order

[dingo-d]

This PR depends on #107. Once that is merged, this PR should be rebased to the master branch.

The PR adds rules about the order of property and method modifiers and is the continuation of the additions of 'modern' PHP code in the WordPress PHP Coding Standards handbook based on the make post by Juliette Reinders Folmer.

[jrfnl]

Should we mention the readonly keyword (PHP 8.1 properties) and property type declarations (PHP 7.4) somewhere in this section ? Or leave it for now until there is sight of a WP minimum PHP version bump ?

Or maybe we should split this into two paragraphs ?

• Properties (visibility, static, readonly, type)
• Methods (abstract/final, visibility, static)

[dingo-d]

If we add readonly and we split this to properties and methods, should we have a paragraph for readonly classes as well?

So we'd have:

• Classes (abstract/final, readonly)
• Properties (visibility, static, readonly, type)
• Methods (abstract/final, visibility, static)

@jrfnl @GaryJones any thoughts on this?

[GaryJones]

I think this needs rebasing to be easier to review.

[dingo-d]

@GaryJones I've rebased it, should be easier to review now 🙂

[jrfnl]

If we add readonly and we split this to properties and methods, should we have a paragraph for readonly classes as well?

We just discussed this and I agree, I think having a separate paragraph for each would be good. Though IMO that would mean four paragraphs:

• Classes (abstract/final, readonly) => mind: enums also have a type (but that goes after the enum keyword.
• Constants (visibility) - not that interesting yet as there is only one type of modifier allowed, but there has been talk about allowing type declarations there too
• Properties (visibility, static, readonly, type) - note: static/readonly are currently mutually exclusive.
• Methods (abstract/final, visibility, static)

[jrfnl]

Reviewed. I hope I caught everything.

Not sure we'd want to have the PHP #.#+ markings inline with the actual order rules, but there were some "if available"s, so either do it with all or don't do it with any of them and just let it be noted in the PHP info block.

[dingo-d]

I'd leave out the PHP comments in the brackets and just have the [info] shortcode at the end.

[GaryJones]

I wonder if this could all be simplified down as per https://www.php-fig.org/psr/psr-12/#46-abstract-final-and-static, which says:

When present, the abstract and final declarations MUST precede the visibility declaration.

When present, the static declaration MUST come after the visibility declaration.

We'd need to add in readonly, and types, but it seems that it could then be covered in just one or two code snippets.

[dingo-d]

I'm fine with having one code example covering all the things, we opted for splitting it into several paragraphs for easier maintenance.

[dingo-d]

@GaryJones I've made some changes based on the discussion I've had with Juliette:

• Left the specific parts about the order for certain OO constructs
• Create only one code example with correct and incorrect usage
• Added bullets to the info block (we have a similar info block for the type declaration)

Does this seem a bit more manageable?

[jrfnl]

Just one small comment, other than that: LGTM!

[GaryJones]

✅