The TWG coding standards committee is announcing two coding standards changes for final discussion. These appear to have reached a point close enough to consensus for final completion. The new process for proposing and ratifying changes is documented on the coding standards project page.
The four new issues being proposed are:
- [policy, no patch] Standardize indenting on chained method calls
- [Policy, no patch] Delete permission to pad spacing in a block of related assignments
- [Policy, no patch] PHP 5.4 short array syntax coding standards
- Add type hinting to function declaration coding standards
Issues still open for comment:
- Should we require a blank line after <?php? (I think we have consensus on this one - to be reviewed on Friday 4/29)
- Allow camelCase also for local variables / parameters (the committee is drafting a comment)
These proposals will be re-evaluated during the next coding standards meeting currently scheduled for April 29th. This is a shorter window and a longer list than the committee generally provides and these issues will likely not be finalized until the following meeting (date TBD due to DrupalCon). The normal timeline was shifted by the arrival of committee member's babies, everyone's happy and healthy but timelines went whacky. At that point the discussion will likely be extended, or if clear consensus has been reached the policy may be dismissed or ratified and moved to the ‘update documentation’ step.
Comments
These proposals will be
Why Drupal making code style in Private talk? We have 3000 contributors in CORE. Can't allow us to vote on the final proposal. (Let's say Top 100 ? Top 500 to vote ?)
For example:
https://wiki.php.net/rfc/shortsyntaxforarrays
diff group of developers has diff views.
These standards aren't about Security & Code Performance. It need not experts to make a right decision.
Coding standards was flagged
Coding standards was flagged to the TWG as an area where conversations would happen, then fizzle out, and no actual change would be made ... either due to a lack of understanding over how to make the consensus 'official', or due to an inability for the community to come to a consensus.
The role of the coding standards committee is to facilitate the discussion, and ensure that these conversations are followed through to a conclusion instead of stalling 'ad infinitum'. This does not mean that the coding standards committee is making the decision ... all issues are still debated in open issues, and any and all community members are encouraged to provide their input.
What this announcement means is that the issues either appear to be approaching consensus (and will soon be either marked 'fixed' and ratified into our standards, or closed), or the conversation has stalled on a key issue that the committee would like to see resolved. Consider it a 'heads up' for anyone who might want to contribute to the discussion, but hasn't discovered the existence of the various issues/proposals on their own accord.
Thanks. But who and how made
Thanks.
But who and how made the final decision? It's unclear. Can the TWG discuss it in next meeting?
I believed Public discussion only helped us to kick out impossible options. For example:
PHP array
[]can't backport to D7. Or some code style bad for GIT history.After than that
["a", "b" => ["A", "B", "C"], "c"]OR
["a",
"b" => ["A", "B", "C"]
"c"
]
OR
array("a",
"b" => ["A", "B", "C"],
"c"
)
it's Apple & Orange.
"Announced for final
"Announced for final discussion" means that we want to wrap this one up. The process indicates that, after an initial two weeks discussion period, the coding standards committee will review the issue to determine whether i) there is a clear consensus or overwhelming preference, ii) more discussion is needed to resolve the issue, or iii) the discussion has reached an unresolvable impasse, requiring escalation or intervention.
In the case of iii), then the coding standards committee would generate a recommendation; though I wouldn't consider this issue as falling under that category. Otherwise, the "final decision" was made as it always is ... by the community through a process of open discussion in the issue queue ... and the job of the coding standards committee is to ensure that the change/proposal is published and communicated.
Thanks.But who and how made
Thanks.
But who and how made the final decision? It's unclear. Can the TWG discuss it in next meeting?
I believed Public discussion only helped us to kick out impossible options. For example:
PHP array
[]can't backport to D7. Or some code style bad for GIT history.After than that
["a", "b" => ["A", "B", "C"], "c"]OR
["a",
"b" => ["A", "B", "C"],
"c"
]
OR
array("a",
"b" => ["A", "B", "C"],
"c"
)
it's Apple & Orange.
Can't find my previous comment
I know that I commented on one of your previous status updates about whether we should move Drupal's coding standards closer to PSR2 by accepting the "open bracket on the next line" rule. See:
Drupal's standard: https://www.drupal.org/node/608152
VS
PSR2: http://www.php-fig.org/psr/psr-2/#4-1-extends-and-implements
Perhaps this was discussed about elsewhere and I'm not able to discover that conversation? Perhaps I'm being ignored and we'll make no progress this year on evolving our code standards to comply with PSR2?
Please let me know how I can be a positive force in this effort
Software Engineer @ The Nerdery
I don't recall this
I don't recall this particular issue being reviewed at any of the coding standards meetings as of yet ... the first step would be to open a dedicated issue with the proposed change in the 'coding standards' project on drupal.org, so that other community members can have an opportunity to provide their input.
Done
https://www.drupal.org/node/2713641
Software Engineer @ The Nerdery