coding standards

I have recently discovered the great joy of reviewing CVS applications for Drupal. I am serious, I love looking at code and directing Drupal developers early on into using Drupal Coding standards and best practices for Drupal development. I have also noticed a number of similar things, so I would like to write a quick post about some basics as to creating a Drupal module that can get a CVS account.

Please note that, these are not necessarily a part of the CVS Application Requirements, and I do NOT speak for the Drupal Infrastructure team or other reviewers of applications. This is just things that I notice and suggest when I do my review, and I feel are important when creating and contributing a Drupal module or theme, a lot of which can already be found on the often-overlooked things to expect (and I should add to as well). Also, I am quite aware that my code is not perfect, but that does not mean I am not capable of directing people in the right direction.

It may be good for perspective to tell you that, honestly, I don't even install the module that I am reviewing most of the time; I just look at the code. I make the assumption that if you are sharing it, you have already used it and tested before applying with it. In some people's eyes, this may seem irresponsible, but I feel it is a safe assumption to make.

Requirements and Other Modules

As the number of contributed modules continually grows on drupal.org, it is more and more important to ensure that new contributors have proved that they have looked at other modules and can describe what their modules do accurately.

• Make sure you read the CVS Application Requirements!
• A lot of this same information is in the what to expect article but is often overlooked.
• Describe how you looked for other modules and ANY module that may do similar things. I need to know you at least looked.
• Are you leveraging other modules in yours? There are a number of stable API modules in Drupal. If applicable, you should use them, or tell me why you are not.
• Is your module a feature that should be a part of another module?
• Tell me that you have read these pages and link to them.
• This is all volunteer work, if you follow this stuff up front, you will save everyone time and make me much happier.
  

Update via Garrett Albright (see comments)

Just a quick tip for managing variables in a Drupal module. Please prefix your variables with your module name. For example:

variable_set('examplemodule_variable_name', 1234);

This ensures that another module won't override your variable, or your module won't do the same thing. Pretty simple. But what is also nice, is that you can clean up after your module a lot easier in the uninstall hook:

/**
 * Implementation of hook_uninstall().
 */
function examplemodule_uninstall() {
  // Get global variable array
  global $conf;
  foreach (array_keys($conf) as $key) {
    // Find variables that have the module prefix
    if (strpos($key, 'examplemodule_') === 0) {
      variable_del($key);
    }
  }
}

Please note that the above convention could cause problems if your module name is something like content_permissions and then the content module (CCK) defines a variable with a conflicting name. All the more reason to make your module names more unique and without underscores.