Drupal already has a solid coding standard. It helps us create code that is predictable and clean, while putting to bed lots of trivial, time-wasting holy wars (e.g., spaces vs tabs). But the coding standard – good as it is – has its limits. I propose we extend the coding standard to include common design patterns and exclude certain anti-patterns.

This talk will move through some common anti-patterns – e.g., the early bail, the assign and evaluate, the anonymous return – and argue for their codified exclusion from Drupal. It will also explore employing a standard which recommends, or even insists upon, certain design patterns in our code – e.g., extracting explicit functionality from a hook_form_submit() or a hook_cron().

In other words, we will ask: what if we made some of the more boring parts of Drupal – the grinding out of hooks, the cookie-cutter programming – even more rote and predictable?

The benefits would be threefold:

1) More time to focus on the truly interesting parts of the code (the non-cookie-cutter bits)
2) Cleaner and even more predictable code
3) A clear end to smoldering debates about the "right" design pattern

Can such a standard be agreed upon? Can it be enforced? Is it worth the effort? Let's explore these questions and more!