Q:

Coding standards for long strings?

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?

A:

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.

