Problem/Motivation

This section is obsolete as it doesn't apply to Drupal 8 and beyond:

Persistent variables (variables/settings defined using Drupal's variable_get()/variable_set() functions) should be named using all lowercase letters, and words should be separated with an underscore. They should use the grouping/module name as a prefix, to avoid name collisions between modules.

Benefits

If we adopted this change, the Drupal Project would benefit by ...

Three supporters required

  1. {link to user}
  2. {link to user}
  3. {link to user}

Proposed changes

Provide all proposed changes to the Drupal Coding standards. Give a link to each section that will be changed, and show the current text and proposed text as in the following layout:

1. https://www.drupal.org/docs/develop/standards/php/php-coding-standards#s...

Current text

Add current text in blockquotes

Proposed text

Add proposed text in blockquotes

2. Repeat the above for each page or sub-page that needs to be changed.

Remaining tasks

  1. Create this issue in the Coding Standards queue, using the defined template
  2. List three supporters
  3. Create a Change Record
  4. Review by the Coding Standards Committee
  5. Coding Standards Committee takes action as required
  6. Tagged with 'Needs documentation edits' if Core is not affected
  7. Discussed by the Core Committer Committee, if it impacts Drupal Core
  8. Documentation updates
    1. Edit all pages
    2. Publish change record
    3. Remove 'Needs documentation edits' tag
  9. If applicable, create follow-up issues for PHPCS rules/sniffs changes

For a fuller explanation of these steps see the Coding Standards project page

Comments

joachim created an issue. See original summary.

avpaderno’s picture

Until Drupal 7 is still supported, that part is not obsolete.

joachim’s picture

It should at least be changed to say it only applies to D7.

avpaderno’s picture

variable_get() and variable_set() are Drupal 7 functions. While it is not explicit that is about Drupal 7, and it could be made explicit, that should not be cause of misunderstanding so much to require a change before Drupal 7 stops to be supported.

quietone’s picture

Issue summary: View changes

I have updated this issue to use the new Coding standard template. We are finding it very helpful.

quietone credited Cyril42.

quietone’s picture

I found a duplicate of this. It is suggesting;

Maybe add a link to https://www.drupal.org/docs/8/api/state-api/overview and add some examples.

.

I have closed that and am adding credit here.

quietone’s picture

Now that Drupal 7 is EOL, I think it is safe to remove all references to Drupal 7 specific standards.

quietone’s picture

Issue summary: View changes

Add link to section to remove

avpaderno’s picture

Rather than removing that part, it should be updated to mention classes, methods, or functions the supported Drupal releases support.

joachim’s picture

There isn't an exact replacement, and in any case, that's information about Drupal's APIs -- it doesn't belong in the coding standards.

avpaderno’s picture

Truly, it is not an API requirement, since a module could call variable_del() using a name for a persistent variable that module didn't define. Similarly, the state API, which is one of the replacements for the persistent variables API, does not require a module to use a specific state name.

quietone’s picture

Is there any convention for the naming of State keys?

avpaderno’s picture

The state key names for state values created by Drupal core modules are prefixed by the module machine name followed by a period. Examples of those keys are system.cron_last, or comment.node_comment_statistics_scale.

Similar convention is used for the configuration object names. From automated_cron.settings, I gather the machine name of the module defining the configuration object.