Drupal coding standards

The Drupal coding standards are the written rules for how code is formatted, named and documented in Drupal core and contributed projects. They cover PHP and the other languages a Drupal project uses. They exist so that code from many authors reads the same way, and tools can check most of the rules automatically.

How the coding standards work in Drupal 11

The current text lives on the Coding Standards site hosted on drupalcode.org. The older pages on Drupal.org are marked obsolete or deprecated and point there. The sections are PHP, Accessibility, CSS, JavaScript, SQL, Twig, Markup, Spelling, YAML and Composer.

The PHP rules most people notice first:

• Indent with two spaces and never with tabs. Use Unix line endings and no trailing whitespace.
• Keep lines of code to 80 characters. Long function names, definitions and variable declarations may go beyond that.
• Put declare(strict_types=1); on its own line after the opening PHP tag, with blank lines around it.
• Name classes and interfaces in UpperCamel, methods and properties in lowerCamel, and constants in capitals with underscores. Interfaces end in Interface and traits in Trait.
• Add parameter and return type hints to all new functions and methods.
• Document every function, class, class member and file with a docblock that starts with a one-line summary under 80 characters. Comments and names use US English spelling.

Checking the rules

The Coder project provides the rules for PHP_CodeSniffer. Drupal core ships its own ruleset, core/phpcs.xml.dist, which lists only the sniffs that already pass. Core also lints with ESLint for JavaScript and YAML and Stylelint for CSS through scripts in core/package.json, such as lint:core-js and lint:css.

Example

<?php

        declare(strict_types=1);

        namespace Drupal\my_module;

        /**
         * Provides a greeting.
         */
        class Greeter {

          /**
           * Builds a greeting for a name.
           *
           * @param string $name
           *   The name to greet.
           *
           * @return string
           *   The greeting.
           */
          public function greet(string $name): string {
            return 'Hello ' . $name;
          }

        }

To check a module with the file extensions the Coder README lists, run phpcs --standard=Drupal --extensions=php,module,inc,install,test,profile,theme,info,txt,md,yml web/modules/custom/my_module. Run phpcbf with the same options to fix what it can.

Common mistakes

• Leaving out the extensions. Every command in the Coder README passes an explicit --extensions list that includes module, install and theme. Keep that list, or store it in a phpcs.xml.dist file as the README suggests and core does, so Drupal's own file types are part of the check.
• Adding type hints to old public code. This breaks backward compatibility. The standard asks for it only in a major version, after a deprecation warning in an earlier minor version.
• Changing style inside a file. Variables may be lowerCamelCase or snake_case, but pick one and keep it within the file.

For marketing and content teams

If an agency writes a custom module or theme for you, ask whether the code passes PHP_CodeSniffer with the Drupal standard. A clean report is a quick, objective check that the code is formatted and documented the way other Drupal developers expect, which makes it easier to hand over to the next team.

Sources

• Drupal coding standards (project home)
• Drupal coding standards: PHP coding standards
• Drupal coding standards: PHP API documentation
• Coder project page on Drupal.org
• Coder 9.0.1 README
• Drupal.org: Coding standards (obsolete page that points to the new location)
• Drupal core phpcs.xml.dist (11.4.10)