Core and contrib use two ways to define associative arrays:

$form['title'] = array('#type' => 'textfield', '#title' => t('Title'));

$form['title'] = array(
  '#type' => 'textfield',
  '#title' => t('Title'),
);

The second way is much more readable. I suggest we add a rule to the coding standards arrays should be defined like that.

Comments

cweagans’s picture

cweagans
He/Him
Primary language English
Location Boise, ID, USA
commented
Status: Active » Needs review

+1

I agree 100%

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

That's what we do with DBTNG too..

Two exceptions:

arrays that just have values, example:

$blah = array('some', 'values', 'without', 'keys');

Arrays that contain only a single value:

$bla = array('key' => $value);

I think it doesn't make sense to split these to multiple lines.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

If we put arrays with one key-value pair on a single line we need an exception to the rule again. I say we use the multiline approach as soon as we specify keys as well. Use cases are markup elements in forms. They generally (only?) have one property, but if that property's on a new line, the element is easily recognisable.

jayavelraj’s picture

jayavelraj commented

We are talking about associative arrays. There is no question of "arrays that just have values" if it is an associative array.

I think its good to stick on with the second one since it is more readable.

$form['title'] = array(
'#type' => 'textfield',
'#title' => t('Title'),
);

As far as "Arrays that contain only a single value" I agree with you for having an exception.

cburschka’s picture

cburschka
they
commented
Status: Needs review » Active

This is not a patch. Also, it seems the mailing list might be a better place to discuss standards... but that's a matter of opinion.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Status: Active » Needs review

The status doesn't necessarily have to do with patches. The proposal still needs review.

axyjo’s picture

axyjo commented
Issue tags: +Coding standards

Tagging + subscribing.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

Adding a general purpose rule for this makes no sense.

We may consider a "recommendation" for form structures and renderable arrays to write them on multiple lines.

But then again, there's no good reason to wrap something that fits into 80 chars. This is the general purpose rule of thumb we really follow.

montesq’s picture

montesq commented
Status: Needs review » Closed (fixed)

I think that http://drupal.org/coding-standards#array sums up clearly the situation. As a consequence, I suggest to close this issue

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Title: Coding standards: arrays » [Policy, no patch] array coding standards
Status: Closed (fixed) » Active

We have this in \Drupal\Core\Entity\EntityNG now, which is just insane:

  protected $values = array(
    'langcode' => array(LANGUAGE_DEFAULT => array(0 => array('value' => LANGUAGE_NOT_SPECIFIED))),
  );
cweagans’s picture

cweagans
He/Him
Primary language English
Location Boise, ID, USA
commented
Title: [Policy, no patch] array coding standards » Coding standards: arrays
Status: Active » Closed (fixed)

That's not something we need to reopen this issue for. Go file a patch to fix it in \Drupal\Core\Entity\EntityNG. It's 98 characters long, and in clear violation of the agreed upon coding standards.