We have formal coding standards for Drupal and I think following those coding standards should be a hard requirement for any patch to get in to core.
qa.drupal.org already has support for running Coder reviews over all submitted patches. What it doesn't do is return a failed test in the event that code style is bad.
So what I'm proposing here is a few things:
- Contrib patch: Ensure that all coding standards are being detected by Coder. #1266450: Identify and implement coding standards not covered by Coder Review
- Code change: Clean up all code style errors in code per the Code Review tab on http://qa.drupal.org/head-style. #1266446: Core-wide code style cleanup
- Policy change: Require that all new patches comply 100% with the coding standards (perhaps as a Gate. If a patch is following code standards, but coder reports that code standards are not met, a patch should be submitted to Coder. #1266454: Policy change: Require perfect code style for all new patches
- CI change: Make qa.drupal.org return failing tests for bad code style. #1266444: DrupalCI should return failed for poor code style - php
Suggested Approach
So that we don't have a huge slew of patches, webchick suggested that we write a script to take care of the code style changes. Grammar Parser and Coder may help with this.
In addition, the coder code style review doesn't detect certain issues and returns false positives on some issues.
Not detected example: Comments should be written with a leading active verb and a period at the end, like this: "Returns such and such object containing foo." Coder (when I checked yesterday) did not detect that error (which is present in authorize.php).
False positive example: update.php does not have translatable strings (there's no instance of t() or get_t() anywhere in the file). Coder still reports that strings should be wrapped in t().
Comments
Comment #1
aspilicious commentedsub
Comment #2
lars toomre commented100% agree with this initiative and have suggested previously that a coder review be an automatic part of the new module application process. It would be great if this became part of both core and contrib patch testing.
I think though that the coder review only needs to be run on the files in the patch that are created or updated. There is little sense in checking those files that are being deleted (e.g. recently deleted profile module files).
Comment #3
webchickSubscribe!
Hm. Possible related/duplicate issue? #1299710: [meta] Automate the coding-standards part of patch review
Comment #4
pillarsdotnet commentedYup; definitely duplicate.
Sorry about that.
Will merge later, but should this go into PIFR queue or stay in Drupal core?
Comment #5
pillarsdotnet commentedClosed as duplicate of #1299710: [meta] Automate the coding-standards part of patch review
Added information from here into the other issue summary.
(Sorry about the fact that this issue is older, but the other issue had better organized / more complete info, and was already posted to the correct queue.)
Comment #5.0
pillarsdotnet commentedAdded issue numbers.
Comment #6
yesct commented