This meta issue to tackle an issue in D7 core: coding standard. My goal here is to have a Drupal 7 that passes Drupal coder.

It's a huge task but we need to get over it. It's important to provide a good code quality:

  • To help people understand how in-depth mechanisms,
  • To provide better fixes,
  • To make our IDE happy with a good auto-completion and type hinting.

However, to do this, we have to go through the D7 code from the bottom to the top, and we will probably see small stuff that could be fixed in a follow up (small perf improvements, obvious bugs, etc etc).
But warning, the goal here is not to alter the way D7 core is working, just focus on coding standard.

Things that we should not do:

  • Change the PHP logic and syntax inside functions/methods

Things that we should avoid doing:

  • Changing functions signatures, we do not have to change the Drupal API in here.
  • Changing function return values

As @dawehner said:

In order to fix core coding standards in a maintainable way, all our coding standards issues should be done on a per-rule basis across all of core, rather than fixing standards in individual modules or files.

It means that we have to create a patch that fixes each of these sniffs individually, this is why this issue is a meta issue.

In order to speed up the process, I propose to use Github and specifically named branches instead of patches.

Ex, to fix the sniff Drupal.Commenting.FunctionComment, create a branch named: "Drupal.Commenting.FunctionComment" and submit a PR against my Drupal 7 repo.

Here's the first PRs... more to come:

To contribute to this issue, install Drupal coder:

  1. cd /path/to/a/virgin/drupal/7
  2. composer require drupal/coder

Then, to have an overview of all the issue to fix:

./vendor/bin/phpcs -p -s --standard=vendor/drupal/coder/coder_sniffer/Drupal --ignore=vendor/ --warning-severity=0 .

The -s flag will add the name of the Sniff.

So, if you want to check a particular sniff, you can do:

./vendor/bin/phpcs -p -s --standard=vendor/drupal/coder/coder_sniffer/Drupal --ignore=vendor/ --warning-severity=0 --sniffs=Drupal.Commenting.FunctionComment .

Here's a Google Drive spreadsheet with the current status.

Comments

Pol created an issue. See original summary.

Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
Pol’s picture

Issue summary: View changes
izus’s picture

+1
as a module maintainer, i usually pick from the core just because "core does it like this".
if core respects coding standards, contrib are very likely to follow as developers digg into core to get some easy to hack snippets ;)

ianthomas_uk’s picture

-1
The benefit of most of these changes is pretty small but the are some big costs.

the time to create each patch
The time to rtbc each patch
The time for a committor to review each patch
The time to reroll patches from other issues that were broken by these changes (there will be a lot). Some patches may never get rerolled and we would lose that fix
The chance of something breaking. I've seen far too many "perfectly safe" changes that end up breaking something
Further divergence of D7 and D8 codebases
Noise added to git history
Big updates for users to review when they update Drupal core for their sites

Drupal 7 is a legacy platform and the focus should be keeping it stable, making sure nothing breaks. If you want to improve compliance to coding standards do so in D8 where the benefits will be felt for longer.

jonathan1055’s picture

Title: [meta] Fix coding standard in core » [meta] Fix coding standards in core 7.x

This issue has the same title as its parent #2571965: [meta] Fix PHP coding standards in core hence retitle here for clarity

quietone’s picture

Category: Task » Plan
Parent issue: #2571965: [meta] Fix PHP coding standards in core »

@jonathan1055, thanks for updating the title to make is clear.

This does not need to be a child of the other Meta, completing the parent is not dependent on the state of the Drupal 7 code. I am removing the parent.