Coding standards v3

[danepowell]

The goal of v3 is to simplify and decouple the standards, as described in the readme:

• Projects (e.g., Drupal modules) targeting the Drupal community should adopt a Drupal ruleset. This will no longer be based on AcquiaPHP, but on the Drupal standard. All others should adopt a general PHP ruleset, which will be based on PSR-12.
• Public projects (e.g., open-source Drupal modules) should adopt a non-strict ruleset to facilitate external collaboration. Non-strict rulesets will be nearly identical to their base standards. All others should adopt a more opinionated internal/strict ruleset.

To do:

• Should we rename these to match their intended audience (public/private projects) instead of describing the ruleset itself (strict/non-strict)?
• Test on a representative set of projects to gauge the LOE for migration from v2

References:

• Example migration for Acquia CLI (AcquiaPHPStrict): Coding standards v3 cli#1762

[TravisCarden]

This is great. I have some suggestions in the comments. I also have one concern related to stability:

Firstly

If we're including whole upstream rulesets indiscriminately (as opposed to rule-by-rule), we run the risk that upstream changes and additions will cause sudden, unexpected failures when projects update their dependencies.^[1] We could pin to specific versions to avoid that, but then we expose our users to version conflicts. I wonder if we shouldn't do this:

1. Literally copy the entire upstream rulesets into ours so that we can release breaking changes on our own schedule.
2. Create separate "Edge" standards for Drupal and PHP and add new upstream rules there so that changes are completely predictable.
3. Possibly create a CI job to detect upstream additions so we're sure to notice and add them.

Secondly

As to whether we should rename these to public/private, that's a different way of thinking about the whole distinction than we've used in the past. We previously implied that "Strict" was better if you could manage it, whereas now it seems like we're saying they're actually appropriate or inappropriate based on context. I'm fine with the shift, but public vs. private doesn't seem quite right to me. It seems more like open source vs. proprietary. This represents late developing on my part and conflicts with some of my comments on the actual code, but I think it might actually address some of the discomfort I was expressing there.

---

[1] Unless all of our upstream dependencies carefully observe Semver, which we can scarcely hope for, much less depend on.

[TravisCarden]

I found a few little things I went ahead and just fixed real quick. I'm happy with it now. Ship it! 🙂