Identifying good practice in Drupal website development

The flexibility of the basic Drupal system and the richness of its ecosystem means that there are a variety of ways to accomplish the same task. The question, therefore, then becomes what is best practice? A question that generally translates into "what is the overall community consensus about what is the 'right thing to do' when faced with a particular problem".

Now, donning my pedantic hat for a second, it has always struck me that "community consensus" does not mean best practice. Firstly because the general consensus can be wrong and lead to bad solutions (although that generally does not happen) and, secondly, because there can be more than one good solutions and the most popular one is not necessarily better than an alternative but equally good one.

For me, best practice should be identifiable on its pure merits. On whether it passes a set of tests that mean that it is the right thing to do. Knowing which are those tests and then being able to apply them means that you can immediately decide for yourself if your idea of how to solve a problem is at least viable before you look into the wider community for alternatives. This is especially important in settings like Drupal development where actually just finding a good solution is a challenge.

So what are the tests that will enable you to identify a solution as good practice. I will try to least some of mine but I am hoping that others will chime in with more and we will be able to put together a good list.

How decoupled is it?

Say you need to change the value of a certain node field every time that node is saved based on a number of criteria. A simple hook_nodeapi will get you in and out in no time. Question is, where do you place this hook_nodeapi. Well, in a module named after the site alongside all my other hacks and tricks of course! It is my "secret sauce" don't you know?

I have seen hook_nodeapi functions worthy of Oscars for the amount of php theatrics they are able to execute. But the result is a huge mess of code where you cannot just switch things on and off as you like.

You need to decouple. Better to have small modules do just one or two related things. This way you can switch them on and off at will and can focus on a specific task at a time. Unless you must guarantee that changes through hooks happen in a certain way or if it is a really, really simple change I would strive for as much de-coupling as possible.

Is it happening at the right level?

Functionality, logic issues should be in modules, theming issues in themes. I know you can have php in template files, in blocks through that darned PHP filter and do practically anything you like anywhere but that does not mean you should be doing it there.

Similarly, within theming or logic you should be doing things at the right level. If, for example, you are theming a view you should try use the right template name file from the variety you can choose from. If it is specific to just one particular view and should not affect any other view use then don't use a generic template file to theme it. Don't go for the general one thinking "this is the only grid view I have in the system I'll just use the generic grid tpl file". Another grid-type view is going to pop up a year down the line and you will be left wondering why the hell it is coming out the way it is!

Can you track changes in a versioning system?

This kind of goes with the one above. Things stored in the DB can't really be tracked via versioning. Things stored in files can. Keep the DB as free of configuration details as possible. Now, I know Drupal doesn't actually help with this. But modules like Features and Exportables are trying to do their best.

Are you building it yourself even though you know it could probably happen via Views, Panels, CCK, Node Display, FormAPI, ?

Stop then. Go back and figure out how to do it with the modules that are already installed on your site. Unless you are absolutely certain that your way is better in some significant manner then it is not worth it. Those modules are used on thousands on sites everyday and they are just safer banks to bank with. Not to mention the kudos points this will earn you with the next developer that comes along to work on the site and will be greeted by familiar faces he or she already know how to deal with rather than some kid they've never heard of (that may be brilliant) but is going to take time to know.

This does not mean you should try to find a module for every single thing before you do something yourself. Unfortunately not all modules are born equal. But there is a set of at least 100 modules that are of really high quality, can get you very far and if you are serious about Drupal development and saving time to have a beer you should get to know them!

I think that's a good set to start with. Please let me have some of yours - it would be great to have a good list to refer to.