Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
- #2135291: [Policy, no patch] PHP 5.4 short array syntax coding standards for Drupal 8 is a proposal that has a lot of support and therefore likely to be approved. However, it's not suitable for any project with less than a PHP 5.4 requirement, which includes Drupal 7 core and most Drupal 7 contrib modules.
- #1158720: [policy, no patch] Add parameter type hinting to function declaration coding standards is an approved coding standard, but per #1158720-38: [policy, no patch] Add parameter type hinting to function declaration coding standards, contrib modules and possibly core might not be able to implement it in some places without breaking BC.
So, what is the best way to approve/document such evolutions to our coding standards, while still accommodating existing code to not adhere to them?
Proposed resolution
?
Remaining tasks
Discuss
Comments
Comment #2
klausiFrom https://www.drupal.org/coding-standards
Keep it simple: only one version of coding standards with current best practices. Old code may violate it, which is ok.
If there are special cases just mention it in the standards:
* Short array syntax: "Note that code written for Drupal 7 and before should not use short array syntax because it should be compatible with PHP 5.3 which does not have the short array syntax."
* Parameter type hinting: "Note that for backwards compatibility reasons existing code without type hints is allowed."
Comment #3
David_Rothstein CreditAttribution: David_Rothstein as a volunteer commentedI agree with @klausi - there are good reasons the coding standards are version-agnostic (simplicity, less confusion when backporting patches, etc) and exceptions to that for "technical" reasons are probably rare enough that it makes sense to just document those inline with the specific coding standard.
If I were to suggest any changes it might be to this:
Which is a little wishy-washy. We should probably at least strongly encourage the updating of old code (at least for Drupal core) after a new coding standard is adopted, even if it isn't a strict requirement. Because if contributors adopt a new coding standard when writing new code but the old code is never updated, then the codebase just winds up being inconsistent.
Comment #4
pfrenssenI personally don't think we should have different versions of the coding standards. I fully agree with @klausi that it should not be expected that people have to update old code to comply to new standards:
In addition to this, I don't think we ever need to hold back on adding a new rule to Coder because "some old code might not be compatible". There are ways to handle use cases where a particular project needs to ignore certain newly added coding standards rules:
@codingStandardsIgnoreStart
and@codingStandardsIgnoreStart
tags to exclude the affected section from coding standards checks, preferably with a short explanation of why the standard is not being followed.phpcs.xml.dist
file that excludes the incompatible sniff for the entire code base.These potential B/C breaking changes are quite rare, so the burden of maintaining these exclusions is low.
I do think that potentially B/C breaking changes should come with a warning. Like @klausi suggested:
Comment #5
quietone CreditAttribution: quietone at PreviousNext commentedThere has been no discussion here for 7 years and the three comments support the existing practice that 'Drupal coding standards are version-independent and "always-current"'. #4 also provides options for working with 'old' code.
The Issue Summary asks for clarification, therefore I am changing to a support request. I am also closing as fixed because of the 3 answers.