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.

[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)

[dingo-d]

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

[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?