This link has been bookmarked by 81 people . It was first bookmarked on 07 May 2008, by Van Tran.
-
23 Jan 13
-
20 Jan 13
-
02 Jan 13
-
30 Nov 12
-
08 Oct 12
-
06 Sep 12
-
17 Feb 12
Alessandro MascherpaQue bonito se ve el código cuando todos siguen los mismas lineamientos de código: aquí están los de Drupal: http://t.co/UtKSBkIN
-
14 Feb 12
-
22 Oct 11
-
24 Sep 11
-
08 Jul 11
-
04 Jul 11
-
16 Mar 11
-
10 Feb 11
-
09 Feb 11
-
20 Nov 10
-
22 Sep 10
-
13 Sep 10
-
04 Sep 10
-
28 Aug 10
-
24 May 10
-
07 May 10
-
05 May 10
-
14 Jan 10
-
04 Jan 10
-
28 Dec 09
-
23 Dec 09
-
06 Oct 09
-
25 Sep 09
-
02 Sep 09
-
The Drupal Coding Standards applies to code within Drupal and its contributed modules. This document is loosely based on the PEAR Coding standards.
-
Use an indent of 2 spaces, with no tabs.
Lines should have no trailing whitespace at the end.
Files should be formatted with as the line ending (Unix line endings), not \r (Windows line endings).
-
All binary operators (operators that come between two values), such as
+, -, =, !=, ==, >, etc. should have a space before and after the operator, for readability. For example, an assignment should be formatted as$foo = $bar;rather than$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. -
Control structures include if, for, while, switch, etc.
-
Control statements should have one space between the control keyword and opening parenthesis, to distinguish them from function calls.
-
You are strongly encouraged to always use curly braces even in situations where they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.
-
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.
-
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.
-
Arrays should be formatted with a space separating each element (after the comma), and spaces around the => key association operator, if applicable
-
Drupal does not have a hard standard for the use of single quotes vs. double quotes. Where possible, keep consistency within each module, and respect the personal style of other developers.
-
With that caveat in mind: 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
-
Always use a space between the dot and the concatenated parts to improve readability.
-
When using the concatenating assignment operator ('.='), use a space on each side as with the assignment operator
-
Inline documentation for source files should follow the Doxygen formatting conventions.
-
Non-documentation comments are strongly encouraged. A general rule of thumb is that if you look at a section of code and think "Wow, I don't want to try and describe that", you need to comment it before you forget how it works.
Non-documentation comments should use capitalized sentences with punctuation. Sentences should be separated by single spaces. All caps are used in comments only when referencing constants, for example
TRUE. Comments should be on a separate line immediately before the code line or block they reference. -
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. -
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.
-
All source code files in the core Drupal distribution should contain the following comment block in the header:
-
This tag will be expanded by CVS to contain useful information
-
Functions should be named using lowercase, and 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.
-
Constants should always be all-uppercase, with underscores to separate words.
-
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 should be named using "CamelCase."
-
Class methods and properties should use "lowerCamelCase"
-
All documentation files should have the file name extension ".txt" to make viewing them on Windows systems easier. Also, 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).
-
There is a helper command line script included with Drupal to check your code for style compliance. The code-style.pl file is located in the
/scriptsdirectory. To use the script just give your file as an argument when you execute the script (make sure the script is executable):./code-style.pl path/to/file/example.moduleThis will output a list of suggestions for where to improve your code.
-
-
17 May 09
-
07 Apr 09
-
12 Mar 09
KurtAll drupal work should be done according to these standards
drupal programming php development standards coding reference f1ssmith
-
08 Feb 09
-
23 Dec 08
-
10 Aug 08
-
07 May 08
-
04 Mar 08
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.