• OSInet contributions to Drupal
  • Contributions to Drupal core follow the Drupal coding standard.
  • Contributions to non-OSInet contributed code follow the coding convention of said code, usually the same Drupal coding standard as core.
  • Contributions outside core follow the here-defined OSInet coding style.
• Contributions to PEAR follow the PEAR coding standards
• Contributions to the Zend Framework follow the Zend Framework coding style

The OSInet coding style is mostly the Zend Framework style, except for its indenting rules, which follow the second variant of the Whitesmiths / Symbian style with spacing set to two spaces. For HTML the coding style is banner.

Examples on this page are given in the context of a module (Drupal) or class called G2.

All code must work under error_reporting(E_ALL | E_STRICT)

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. Never use parentheses around the returned value (ZF: it can break code if a method is later changed to return by reference).

For long argument lists or long argument names, appropriate line wrapping may be used, like:

public function someFunctionWithALongName(
  $firstParamsHasALongNameToo,
  $secondParamIsAlmostWorse   = 'default',
  $notForgettingOtherDefaults = 0)
  {
  $ret = action;
  return $ret;
  }

Note that for ZF, the code sample supplied in the doc contradicts the doc text. Reference is made to the text. The rules and sample do not specify parenthesing for multiple tests in a clause.

For OSInet, long tests must be wrapped to align readably. Although ZF does not mention this, the line length requirement makes it likely too.

ZF rules for this are implied by the example in the A.4.5.2 section.

Spacing, one-liner: identical Spacing, indented: Different

Note that if the line 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. “⇒” symbols ought to be aligned.

$form['title'] = array
  (
  '#type'        => 'textfield',
  '#title'       => t('Title'),
  '#size'        => 60,
  '#maxlength'   => 128,
  '#description' => t('The title of your node.'),
  );

Additional comma: identical.

OSInet contrib code does not support PHP4, so PHP5 structures like the new object model are standard.

This means that including can make use of the autoload mechanism, which can be more efficient under caching than using require_once with conditional content.

The rule regarding the closing ?> tag is only applicable to “program-type” PHP files, not to HTML pages with embedded PHP, which are mostly out of the scope of these rules.

Identical

Additional rule: modules must define a constant containing the version information to be displayed on the module settings page. See the rules for constants below.

Identical

Variables naming following the rules for functions and methods. Exceptions:

• existing libraries or APIs are not renamed. Facade APIs may be used until existing libraries match the new format
• the standard variable $ret should be used for all return values. Always use it to return a value, instead of directly returning the latest instruction result. This helps with a typical debugger configuration: breakpoint on return and $ret as a watched value.
• some Hungarian notation is used:
  • the name of “unsafe” strings is prefixed by “us_”
  • http://www.joelonsoftware.com/articles/Wrong.html
• naming resulting from external objects applies the rule by pieces. Example:
  • GTK widgets are named <abbreviated class><Instance> within Glade
  • GTK signals are called <signal>
  • Related callbacks are called on_<abbreviated class><Instance>_<signal>
  • Example: on_fmMain_destroy is
    • “on_” : the callback for…
    • “fmMain” : a Main Form GtkWindow widget
    • “_destroy” : the “destroy” GTK signal
  • Rationale: forcing CamelCaps for the standard naming convention would result in onFmMainDestroy, which splits ambiguously and is not a default in Glade, and with Fm being capitalized inconsistently in various places in the app. As an instance instead of a class, it should remain lowercase

• Since PHP4 support is not required, visibility (private, protected) settings on class members are recommended when using PHP5 class constructions.
• functions or methods returning unsafe values are prefixed by “us_” just like variables, as “us_someFunctionName()”
• “final” classes should not contain “protected” members, since they can not have derived classes which would take advantage of the “protected” access.

As of 01/01/2007, see table above. Note that the PHP builtins “null”, “true”, and “false” are lowercase, unlike constants from user code.

Previously, the format was:

define('G2VERSION', '$Id');

This style of coding is now considered obsolete (even under Drupal conventions, the constant should be named G2_VERSION, not G2VERSION), and should be replaced when preparing module versions for Drupal 6 by class constants like G2::VERSION, or more generally Foo::SOME_CONSTANT :

class G2
  {
  // don't forget the PHPdoc here
  const VERSION = '$Id$';
  }

• Drupal mandates some function names, notably, for module “mymodule”:
  • default theme functions must be named theme_mymodule_foo
  • hook_foo implementations must be named mymodule_foo
• Beyond that, all other functions in a module should be defined as static public methods of a class named like the module, like:

// don't forget the PHPdoc comments here
class My_Module
  {
  // and here
  const SOME_CONSTANT = 'bar';
 
  // ... and here too
  static public function foo($op)
    {
    // do something and return
    }
  }
 
// ..which can be invoked as:
My_Module::foo(My_Module::SOME_CONSTANT);