Currently if you have a call to t() that uses variable substitution, you'll get the following error if the line goes longer than 80 characters.

If the line declaring an array spans longer than 80 characters, each element should be broken into its own line

I may be wrong about this, but I think that the $args array within t() is supposed to be an exception to the rule. There are a number of examples in core where the $args array extends past the 80 char mark.

Comments

klausi’s picture

We don't have an exception for t() in the coding standards, and I think that is alright. Consider this (unfortunately drupal.org breaks that line for us, but imagine this is one long line):

$x = t('This is a long line with some text using @placeholder1, @placeholder2 and @placeholder3.', array('@placeholder1' => $foo, '@placeholder2' => $bar, '@placeholder3' => $baz));

versus

$x = t('This is a long line with some text using @placeholder1, @placeholder2 and @placeholder3.',
  array(
    '@placeholder1' => $foo,
    '@placeholder2' => $bar,
    '@placeholder3' => $baz,
  )
);
cameron tod’s picture

Title: $args array within t() triggers error, 'longer than 80 characters' » Don't flag arrays declared in function calls as breaking the 80 character limit

I was working on #1533208: Make contextual module pass Coder Review, and jhodgdon stated that if drupalcs flags up this warning on arrays declared in function calls, then it is inconsistent with the coding standards. This issue is ongoing regarding this: #1539712: [policy, no patch] Coding standards for breaking function calls and language constructs across lines

FWIW, I much prefer the second style and have changed a lot of my code over to that standard now.

traviscarden’s picture

Status: Active » Postponed

The Coding standards only state this with respect to arrays:

Note that if the line declaring an array spans longer than 80 characters (often the case with form and menu declarations), each element should be broken into its own line, and indented one level

Since no exceptions are specified, the sniffer is actually enforcing the the standard correctly as it's written. #1539712: [policy, no patch] Coding standards for breaking function calls and language constructs across lines is about defining exceptions. Until there's resolution there and the standards themselves are updated, any change to the sniffer would have to be based on speculation. It's probably best to wait.

klausi’s picture

Project: Drupal Code Sniffer » Coder
Version: 7.x-1.x-dev » 7.x-2.x-dev
Component: Code » Code Sniffer

Drupalcs has been merged into coder, moving this issue.

klausi’s picture

Component: Code Sniffer » Coder Sniffer
Issue summary: View changes
Status: Postponed » Closed (won't fix)

Coder 7.x is frozen now and will not receive updates. Coder 8.x-2.x can be used to check code for any Drupal version, Coder 8.x-2.x also supports the phpcbf command to automatically fix conding standard errors. Please check if this issue is still relevant and reopen against that version if necessary.