C H A P T E R 2 2

■ ■ ■

Development Best Practices

In this chapter, you’ll find all the little coding tips and best practices that’ll make you an upstanding Drupal citizen and help keep your forehead separated from the keyboard. I’ll begin by introducing Drupal’s coding standards, and then show you how to create documentation that will help other developers understand your code. I will help you find things quickly in Drupal’s code base, introduce version control, walk you through module maintenance, and wrap up by discussing debugging and profiling your code.

Coding Standards

The Drupal community has agreed that its code base must have a standardized look and feel to improve readability and make diving in easier for budding developers. Developers of contributed modules are encouraged to adopt these standards as well. Actually, let me be frank: your modules will not be taken seriously unless you follow the coding standards. I’ll cover the standards first and then introduce a few automated tools to help you check your code (and even correct it for you!).

Line Indention and Whitespace

Drupal code uses two spaces for indentation—not tabs. In most editors, you can set a preference to automatically replace tabs with spaces, so you can still use the Tab key to indent if you’re working against the force of habit. Lines should have no trailing whitespace at the end.

Files should be formatted with a Unix \n as the end-of-line character and not with the Windows standard \r\n. All text files should end in a single newline (\n).

Operators

All binary operators, such as +, -, =, !=, ==, >, etc., should have a space before and after the operator. For example, an assignment should be formatted as c = a + b instead of c=a+b. Unary operators, such as ++, should not have a space between the operator and the variable they are operating on.

Casting

You should put a space between the (type) and the $variable in a cast, such as (int) $count.

487