Six tips to get help with your code

Heine —Mon, 2007/11/19 - 07:10

Six tips for getting help with your code, because efficient use of volunteer time is key in getting good and timely support. While this is somewhat geared towards Drupal support on the Drupal.org forum and in the #drupal IRC channel, the tips apply to nearly all code you need help with.

Post code.
State the goal and the problem.
Post actual code.
Make it short, make it matter.
Make it complete.
Make it readable.

1. Post code.

Without seeing the code, help will be inefficient. While some helpers are very good in psychic debugging, you don't want to rely on the spirits having a good day.

This is the most important of the actions you should take, and initially forgotten on this list as it seemed really obvious. Recent observations on Drupal.org and irc.freenode.net made clear that this is not the case.

2. State the goal and the problem.

If you state what you want to do, and what part is not working, volunteers can focus on solving the problem, instead of combing through your code to find it.

3. Post actual code.

This point is often overlooked, but almost nothing is more aggravating than ending up in a support ping-pong where you need to write multiple times: "O that, well, that is alright in the 'real' code, just a typo here."

4. Make it short, make it matter.

Posting 'real' code does not mean you need to dump your 14,000 line module into the posting form. Unless your code is very short, carefully excise the relevant, but complete part. Doesn't this clash with Tip 3? No, because you can test this summary of the code as well. You'll find that this exercise often uncovers the problem by reducing the complexity (if not the sheer size) of the code.

5. Make it complete.

This point may be controversial, but time and time again we see problems outside the posted snippets (see the post taxonomy_form() giving me problems? on Drupal.org for an example). Consider the following example, which could be titled, "drupal_get_form doesn't get my form". Just posting the form-builder function module_foo_form would not reveal errors to anyone. If the hook_menu implementation was pasted along, a volunteer would immediately notice the missing return statement from mymodule_menu.

While I do not have any statistics to back up the following statement, it seems that volunteers often do not even reply to samples where they don't see a problem. Perhaps afraid they missed something and would look foolish? Anyhow, it's in your best interest to aid bugfixing.

function mymodule_menu($maycache) {
if ($maycache) {
$items[] = array(
'path' => 'mymodule-test',
'callback' => 'drupal_get_form',
'callback arguments' => array('module_foo_form'),
'type' => MENU_CALLBACK,
'access' => TRUE,
);
}
}

function module_foo_form() {
return array( 'bar' => array('#value' => 'HI'));
}

6. Make it readable.

This one is easy. Which is easier to read?

function mymodule_form_alter($i, &$f) {
if($i=='hello_form'){$f['a'] = array('#type'=>'textfield', '#title' => t('Foo Title'),
'#default_value' => 'Baz');
if ($GLOBALS['joomla'] == 'no')
$f['b'] => array('#value' => t("Drupal"));
}
else {
$f['#tree'] = TRUE;
}
}

function mymodule_form_alter($form_id, &$form) {
if ( $form_id == 'hello_form') {
$form['a'] = array(
'#type' => 'textfield',
'#title' => t('Foo Title'),
'#default_value' => 'Baz'
);
if ($GLOBALS['joomla'] == 'no') {
$form['b'] => array('#value' => t("Drupal"));
}
}
else {
$form['#tree'] = TRUE;
}
}

Not formatting your code increases the workload for the people that want to help you, obscures bugs and may project the image that you are lazy.

Heine