2

I've been looking for some official guidelines on how to format long strings in module code, but the closest thing I've found is an ambiguous section on indenting long SQL queries which suggests any of the following styles:

$text = '
  Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean ligula odio,
  hendrerit consectetur porta vitae, sollicitudin sit amet eros. Integer
  hendrerit varius felis id dignissim.
';

$text = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean ligula'
. 'odio, hendrerit consectetur porta vitae, sollicitudin sit amet eros. Integer'
. 'hendrerit varius felis id dignissim.'
;

$text = <<<TEXT
  Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean ligula odio,
  hendrerit consectetur porta vitae, sollicitudin sit amet eros. Integer
  hendrerit varius felis id dignissim.
TEXT;

The Drupal Coding Standards talk about how to use the concatenation assignment operator:

$string .= 'Foo';
$string .= $bar;
$string .= baz();

but they don't actually state whether single long strings should be broken up that way.

To add further confusion, the Coder module handles long strings differently again in its "good.php" test file:

$text = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean ' .
        'ligula odio, hendrerit consectetur porta vitae, sollicitudin sit ' .
        'amet eros. Integer hendrerit varius felis id dignissim.';

Personally, I've just been doing it like this until now:

$text = 'Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean ligula
        odio, hendrerit consectetur porta vitae, sollicitudin sit amet eros.
        Integer hendrerit varius felis id dignissim.';

However, I'd like to start doing it the "right" way (if there is one). Does anyone have a definitive answer?

  • 1
    If it's not already in the coding standards, then there's no definitive answer for the "right" way. That's why you're seeing seeing people's personal preferences, and advice that says "any of these are fine". This one's really more about common sense and making sure long strings are readable than having anything standardised. Personally I prefer HEREDOC if the SQL goes over 80 chars, but that's kind of the point - there's no right or wrong, go with you gut – Clive Oct 30 '15 at 11:47
  • @Clive Fair enough, I see your point. My gut would be to follow the way the Coder module does it, but then I go and read something like this which says we can't do it that way for a string being passed through t() and implies the string should remain on one long unreadable line of code! The alternative then is to pointlessly define a string variable and pass it to t() via a placeholder just to make our code readable, which seems rather silly. – morbiD Oct 30 '15 at 12:27
2

Drupal does not restrict the usage of long strings in code. It is advisable to concatenate each line ($output .= '...';) for a readable code, but as you can see in Drupal code, long strings are not broken up, especially when used with t():

function field_help($route_name, RouteMatchInterface $route_match) {
  switch ($route_name) {
    case 'help.page.field':
      $field_ui_url = \Drupal::moduleHandler()->moduleExists('field_ui') ? \Drupal::url('help.page', array('name' => 'field_ui')) : '#';
      $output = '';
      $output .= '<h3>' . t('About') . '</h3>';
      $output .= '<p>' . t('The Field module allows custom data fields to be defined for <em>entity</em> types (see below). The Field module takes care of storing, loading, editing, and rendering field data. Most users will not interact with the Field module directly, but will instead use the <a href=":field-ui-help">Field UI module</a> user interface. Module developers can use the Field API to make new entity types "fieldable" and thus allow fields to be attached to them. For more information, see the <a href=":field">online documentation for the Field module</a>.', array(':field-ui-help' => (\Drupal::moduleHandler()->moduleExists('field_ui')) ? \Drupal::url('help.page', array('name' => 'field_ui')) :'#', ':field' => 'https://www.drupal.org/documentation/modules/field')). '</p>';
      $output .= '<h3>' . t('Terminology') . '</h3>';
      $output .= '<dl>';
      $output .= '<dt>' . t('Entities and entity types') . '</dt>';
      $output .= '<dd>' . t('The website\'s content and configuration is managed using <em>entities</em>, which are grouped into <em>entity types</em>. <em>Content entity types</em> are the entity types for site content (such as the main site content, comments, custom blocks, taxonomy terms, and user accounts). <em>Configuration entity types</em> are used to store configuration information for your site, such as individual views in the Views module, and settings for your main site content types.') . '</dd>';
      $output .= '<dt>' . t('Entity sub-types') . '</dt>';
      $output .= '<dd>' . t('Some content entity types are further grouped into sub-types (for example, you could have article and page content types within the main site content entity type, and tag and category vocabularies within the taxonomy term entity type); other entity types, such as user accounts, do not have sub-types. Programmers use the term <em>bundle</em> for entity sub-types.') . '</dd>';
      $output .= '<dt>' . t('Fields and field types') . '</dt>';
      $output .= '<dd>' . t('Content entity types and sub-types store most of their text, file, and other information in <em>fields</em>. Fields are grouped by <em>field type</em>; field types define what type of data can be stored in that field, such as text, images, or taxonomy term references.') . '</dd>';

I would stick with this drupal usage, this is the best compromise for usage and good readability. Your first examples looks good, but adds extra line feeds. The second example is not good to read and the third is often used in scripts, but not very common in php code.

  • This is helpful. My question actually stems from the problem of what to do with a long string in a t() call, so seeing from your example that a core module just leaves it all on one line, I'm satisfied enough to accept this answer. I guess when we're not limited by the use of t() it just comes down to personal preference, as Clive commented above. – morbiD Nov 2 '15 at 9:31
  • Clive is right about that, if you don't like the concatenating of drupal, heredoc is the best solution, because this does not add unwanted whitespace. But it does not work well with indentation. I think this is the reason, that it is used more in scripts and not so often in well structured code. – 4k4 Nov 2 '15 at 9:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.