Any Drupal programmer should be familiar with its coding standards. A lot of them look like nitpicking, but following them gives code a consistent appearance and avoids bad practices. A development team will find the code easier to follow when everyone uses the same standards.
The parts that deal just with the appearance of PHP code don’t affect its functionality or compatibility, but they give it a consistent, familiar look, making it easier to read. They include things like putting spaces around binary operators, always using curly braces, and using <?php ?> rather than <? ?>
These requirements help to avoid coding errors. A common mistake is to create a one-statement block without braces and then add more code without remembering to add braces.
if (condition) do_stuff();
Adding another line of code after do_stuff will let it be executed whether the condition is true or not, which may not be what the coder meant. Putting braces around whatever follows the condition makes errors less likely.
Variables, Functions, and Classes
Applying the standards for names makes it easier to tell their purpose and to remember them. We tend to remember names by saying them as words or phrases, so it’s hard to remember whether we used PreviousTime or previousTime or previous_time. Variables should start with lower case, global variables with an underscore, and constants should all be uppercase. Functions should use the grouping or module name as a prefix. Either snake case (lower case with underscore separation) or camel case (capitalizing each word except the first, without separation) is acceptable for variables, but you should make a choice and stick with it.
The standards for object-oriented programming have effects beyond appearance and consistency. They reflect good OOP practices.
The code should declare the visibility of all methods and properties as public, protected, or private. Properties really shouldn’t be public; use getters and setters instead. Making properties public exposes the implementation, making it harder to change the code safely.
The standards encourage defining an interface that’s separate from the class that implements it, especially if there’s any chance of replacing the implementation later. Code which is easy to generalize presents fewer problems later on.
Documentation and Comments
Each file should have documenting comments that conform to the API module. That’s the standard way of generating documentation for Drupal code, and usable documentation is important for later development. Other people may later build on a module, and they’ll need to understand its public interface.
The standards say documentation should use US English spellings. This may annoy some developers, but it makes it easier to search on key terms.
The coding standards don’t cover just PHP, but all the languages that typically go into Drupal modules.
The SQL standards have an effect on the database design as well as the appearance of the code. Developers should use standard SQL, so that they aren’t tied to MySQL or any other server. Certain practices, such as SELECT *, could introduce security risks by unintentionally exposing data.
Developers may not think of CSS as “code,” but Drupal standards apply to it as well. CSS shouldn’t rely on the HTML structure; instead it should rely on classes. New standards are under development for Drupal 8, and there are special rules for themes.
Software development is an ongoing process. It’s not enough for code to run right when it’s tested; it has to be maintainable. A Drupal module that follows consistent standards will be easier to pick up and expand on later. Bugs won’t be as hard to find as they’d be in code which is written any old way. Keeping it up to standard may seem like extra work, but it saves work in the long run.