Skip to main content
Ramdoss

10 best practices for implementing the Drupal coding standards


Drupal coding standard

Learn about the Drupal community coding standards and best practices that every Drupal developer should care whenever writing the code for Drupal. If you are truly committed to Drupal, then you should guarantee the code you contribute back be standards compliant. Here are ten of the best practices for implementing Drupal coding standards:

1. Spacing and Tabbing

  • Use double space (not tab, yes both are different) for indentation 
  • Often, the IDE/Editor that we use for Drupal development aggravates this issue as most of the IDE is configured to use tab for every line-break.
  • Press <ENTER> ensure that it aligns the cursor to the same indent as previous line with tabbing that caused this indentation issue.

2. Code comments

  • Check this link below for Drupal comment standards (https://www.drupal.org/node/1354). Comments are generally defined and used to state what the following line of code or block of code is doing and why we are writing the logic that way if it needs explanation for any future Drupal developer.
  • Three types of comments can be used in Drupal, Single line commenting (starts with //), Multi-line commenting (starts with /*) and Doxygen commenting (starts with /**).
  • Single line commenting and Doxygen commenting has a wide following in Drupal. Even for the comments with more than a line, it is handled with repeat use of single line commenting. The following example shows the usage pattern:

         // The first line of the comment goes here.
        // Some other comment here.
        // Some more comments here.
        // This saves the $node object and creates/updates the node
           node_save($node);

  • Comments are strictly not to be used to invalidate the code, which means you can’t use the comments to comment-out some set of code that you think are not needed. 
  • If you think some block of code is not really needed, just remove them instead of commenting-it-out. 
  • Sometimes you might find, the block of code that may be needed in future but not needed right now. In such instances, you can invalidate the code by placing those unwanted code in the condition like mentioned below.

         if (0) {
         // Some big logic goes here
        // that are not needed in this release for production
        }

  • The above code gets invalidated, that is will not be executed ever as the condition "if (0)" always returns "FALSE", So the block of code inside that condition will not be executed.

3. Naming the function and variables

  • PHP was just procedural at the time of initial Drupal release. So all the coding standard in Drupal follows as such. That means all the function and variables should follow snake  case structure (as of Drupal7), which means variable names should start with small-letter words and underscore should be used to connect the words if the variable is going to contain multiple words. ($snake_case)
  • With the release of Drupal 8, the naming of variables and functions can also be used using camelCase structure, which means variable names should start with small-letter words with uppercase initials for the connective words in case of multi-word variable. (Eg. $camelCase)
  • In either way, we need to follow only one case throughout the file.
  • What we forget is, we mix cases (camelCase and snake_case) sometimes. This should be avoided. Sometimes we define functions without grouping of the function name. In Drupal, all the functions inside a module should be prefixed with the module name, which is called grouping of the function. This helps in avoiding the name conflicts between modules.

4. Uppercase variables

  • According to Drupal coding standard, UPPERCASE variables are considered as constants whether it's PHP constants (TRUE, FALSE, NULL) or Drupal constants (Eg: LANGUAGE_NONE).
  • Sometimes in order to stress the importance of variables, we name the variables in uppercase. This should be avoided.

5. Operator and logical statements

  •  We often forget to leave a space before and after the usage of operator (Eg. if(arg(0)=='node')). According to the Drupal coding standards, all the operators should have single space before and after the operator (Eg. if (arg(0) == 'node')).
  •  Use single space before the start curly braces. The opening curly should be on the same line as the opening statement, guided by single space. The closing curly brace should be on the end of the block and indented to the same level as the opening statement.

6. Line length and Wrapping

  • In general, all lines of code should be no longer than 80 characters. However, there are exceptions to the character limit for the variable and function name that are quite longer when correctly indented.
  • We often wrap the condition of the control statement for readability. Drupal coding standard encourages us to split the multiple conditions and evaluate each complex conditions into a variable and use that in the control statement for better readability.

7. Module placement

As far as Drupal 7 is considered, all the contributed modules should be grouped under the directory called "contrib" in "/sites/all/modules", whereas the custom modules should go inside "/sites/all/modules/custom". In Drupal 8, the same can be followed or utilize the "/module" directory and use the same grouping of the  modules.

8. Writing Javascript

  • Always use Drupal behavior for your custom scripts which runs every time there is change in DOM elements unlike the traditional jQuery.ready which runs only once during the page execution when the DOM elements are ready.

9. Placeholders for translate function t()

  • Use the placeholders for dynamic strings used inside t() function.
  • Generally t() function is used to translate the given strings, sometimes we might use the dynamic strings inside t() function by concatenating the values, which is the not the best practice formulated by Drupal.

     Example:

  • return t('@username, welcome to my website', array('@username' => $account->name));

10. Module file

  • Use the module file only for Drupal hooks and some commonly used custom functions that you need frequently. 
  • Use .inc file to define menu callbacks and other helper functions that are not needed to be defined in module file.

If we all code to standards, Drupal will be a stronger, more performant, more secure platform. Drupal will continue to grow and strengthen it’s community due to the quality of it’s codebase. Anubavam has been building Drupal sites and providing services such as Drupal 8 upgrade and migration services, Drupal E-commerce development services, and more. Anubavam is participating in Drupal core development since 2006 and has delivered 250+ projects to 100+ happy clients in 22 countries worldwide.

Comments

Leave Your Comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
 

start with anubavam today

You have an idea we have engineers to convert your ideas into reality

Request Quote