Method ordering

[dpi]

SlevomatCodingStandard.Classes.ClassStructure has been enhanced. We can now add more detailed method ordering rules now that some issues/PR solved:

• ClassStructureSniff individual methods configuration slevomat/coding-standard#1098
• Custom method groups order slevomat/coding-standard#1679
• https://github.com/slevomat/coding-standard/releases/tag/8.16.0

Proposal 1

Summary of proposed rules:

• top:
  • test setUp()
  • controller create()
  • plugin createInstance()
  • entity baseFieldDefinitions()
  • invoke method
  • form getFormId(), form getEditableConfigNames()
• middle
  • form
    • form (content entity form)
    • build
    • validate
    • submit
• bottom:
  • form actions(), form save()
  • test tearDown()
  • service getSubscribedEvents()
  • __toString()
• test providers will not be bumper against their method. Theres no rule for this. I think it should be okay that these static methods are moved below the public method block.
• method order doesnt have context of the class, eg whether its an entity or form or service. So we're just hoping things fall into line.
• ordering
  • mixed bag of methods, setter/getters, custom methods, etc
  • static methods
  • protected methods
  • private methods

Proposal 2 / Alternate

As visible in a demo PR (not linked), theres quite a large LOC change for proposal 1.

Taking from proposal, but changing some things:

Defer or reconsider static/protected/private ordering.

And actions() / save().

Most others would keep their position simply due to discipline.

[acbramley]

Generally -1 to this, I like the idea but it's too prescriptive

[dpi]

@acbramley mainly I think private/public/static are the most disruptive, the other rules are essentially what we are disciplined enough to follow anyway. I've modified IS with an alternate