The Drupal Coding Standards apply to code within Drupal and its contributed modules.
1) Indenting and Whitespace :
Use an indent of 2 spaces, with no tabs.
Lines should have no trailing whitespace at the end.
Files should be formatted with \n as the line ending (Unix line endings), not \r\n (Windows line endings).
All text files should end in a single newline (\n). This avoids the verbose "\ No newline at end of file"
patch warning and makes patches easier to read since it's clearer what is being changed when lines are added to the end of a file.
2)Operators :
All binary operators (operators that come between two values), such as +, -, =, !=, ==, >, etc. should have a space before and after the operator, for readability.
Ex) $foo = $bar;
Unary operators (operators that operate on only one value), such as ++, should not have a space between the operator and the variable or number they are operating on.
Ex) a++;
3)Casting :
Put a space between the (type) and the $variable in a cast:
Ex) (int) $v;
4)Control Structures :
Control statements should have one space between the control keyword and opening parenthesis, to
distinguish them from function calls.
Ex)
if (condition1 || condition2) {
action1;
}
elseif (condition3 && condition4) {
action2;
}
else {
defaultaction;
}
For switch statements:
switch (condition) {
case 1:
action1;
break;
case 2:
action2;
break;
default:
defaultaction;
}
For do-while statements:
do {
actions;
} while ($condition);
5)Function Calls :
Functions should be called with no spaces between the function name, the opening parenthesis, and the first parameter; spaces between commas and each parameter, and no space between the last parameter, the closing parenthesis, and the semicolon.
Ex)$var = foo($bar, $baz, $quux);
6)Function Declarations :
Arguments with default values go at the end of the argument list. Always attempt to return a meaningful value from a function if one is appropriate.
Ex)
function funstuff_system($field) {
$system["description"] = t("This module inserts funny text into posts randomly.");
return $system[$field];
}
7) Class Constructor Calls :
When calling class constructors with no arguments, always include parentheses:
$foo = new MyClassName();
maintain consistency with constructors that have arguments:
$foo = new MyClassName($arg1, $arg2);
Note that if the class name is a variable, the variable will be evaluated first to get the class name, and
then the constructor will be called. Use the same syntax:
$bar = 'MyClassName';
$foo = new $bar();
$foo = new $bar($arg1, $arg2);
8)Arrays :
Arrays should be formatted with a space separating each element (after the comma), and spaces around the => key association operator,
$some_array = array('hello', 'world', 'foo' => 'bar');
Note that if the line declaring an array spans longer than 80 characters (often the case with form and menu declarations), each element should be broken into its own line, and indented one level:
$form['title'] = array(
'#type' => 'textfield',
'#title' => t('Title'),
'#size' => 60,
'#maxlength' => 128,
'#description' => t('The title of your node.'),
);
Note the comma at the end of the last array element; This is not a typo! It helps prevent parsing errors if another element is placed at the end of the list later.
9)Quotes :
single quote strings are known to be faster because the parser doesn't have to look for in-line variables.
Their use is recommended except in two cases:
1)In-line variable usage, e.g. "<h2>$header</h2>".
2)Translated strings where one can avoid escaping single quotes by enclosing the string in double quotes.
One such string would be "He's a good person." It would be 'He\'s a good person.' with single quotes. Such escaping may not be handled properly by .pot file generators for text translation, and it's also somewhat awkward.
10)String Concatenations :
Always use a space between the dot and the concatenated parts to improve readability.
$string = 'Foo' . $bar;
When you concatenate simple variables, you can use double quotes and add the variable inside; otherwise,
use single quotes.
$string = "Foo $bar";
When using the concatenating assignment operator ('.='), use a space on each side as with the assignment
operator:
$string .= 'Foo';
11)Including Code :
Anywhere you are unconditionally including a class file, use require_once().
Anywhere you are conditionally including a class file (for example, factory methods), use include_once().
Either of these will ensure that class files are included only once. They share the same file list, so you
don't need to worry about mixing them - a file included with require_once() will not be included again by
include_once().
Note: include_once() and require_once() are statements, not functions. You don't need parentheses around
the file name to be included.
When including code from the same directory or a sub-directory, start the file path with ".":
include_once ./includes/mymodule_formatting.inc
In Drupal 7.x and later versions, use DRUPAL_ROOT:
require_once DRUPAL_ROOT . '/' . variable_get('cache_inc', 'includes/cache.inc');
12) PHP Code Tags :
Always use <?php ?> to delimit PHP code, not the shorthand, <? ?>.
This is required for Drupal compliance and is also the most portable way to include PHP code on differing
operating systems and set-ups.
Note that as of Drupal 4.7, the ?> at the end of code files is purposely omitted. This includes for module
and include files. The reasons for this can be summarized as:
Removing it eliminates the possibility for unwanted whitespace at the end of files which can cause
"header already sent" errors, XHTML/XML validation issues, and other problems.
The closing delimiter at the end of a file is optional.
PHP.net itself removes the closing delimiter from the end of its files (example: prepend.inc), so
this can be seen as a "best practice."
13)Semicolons :
The PHP language requires semicolons at the end of most lines, but allows them to be omitted at the end of
code blocks. Drupal coding standards require them, even at the end of code blocks. In particular,
for one -line PHP blocks:
<?php print $tax; ?> -- YES
<?php print $tax ?> -- NO
14) Naming Conventions :
Functions and variables :
Functions and variables should be named using lowercase
words should be separated with an underscore.
Functions should in addition have the grouping/module name as a prefix, to avoid name collisions
between modules.
Persistent Variables :
Persistent variables (variables/settings defined using Drupal's variable_get()/variable_set()
functions) should be named using all lowercase letters, and words should be separated with an
underscore.
They should use the grouping/module name as a prefix, to avoid name collisions between modules.
Constants :
Constants should always be all-uppercase, with underscores to separate words.
This includes pre-defined PHP constants like TRUE, FALSE, and NULL.
Module-defined constant names should also be prefixed by an uppercase spelling of the module they are defined by.
Global Variables :
If you need to define global variables, their name should start with a single underscore followed
by the module/theme name and another underscore.
Classes :
Classes should be named using "CamelCase." For example:
abstract class DatabaseConnection extends PDO {
Class methods and properties should use "lowerCamelCase":
public $lastStatement;
File names :
All documentation files should have the file name extension ".txt" to make viewing them on Windows
systems easier.
The file names for such files should be all-caps (e.g. README.txt instead of readme.txt) while the
extension itself is all-lowercase (i.e. txt instead of TXT).
Examples: README.txt, INSTALL.txt, TODO.txt, CHANGELOG.txt etc.
