Contrib.social

Improve text for parameter type hinting in function declaration

Open on Drupal.org →
Created on 16 May 2011, almost 14 years ago
Updated 17 July 2024, 9 months ago

Proposed update to coding standards

Suggested changes related to type hinting

Benefits

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

Three supporters required

  1. https://www.drupal.org/u/Kingdutch → (2024-07-17)
  2. https://www.drupal.org/u/ → {userid} (date that user added support)
  3. https://www.drupal.org/u/ → {userid} (date that user added support)

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#functdecl

Argument lists may be split across multiple lines, where each subsequent line is indented once.

Always use type hints for arguments. Argument lists may be split across multiple lines, where each subsequent line is indented once.

2. https://www.drupal.org/node/608152#hinting

PHP supports optional type specification for function and method parameters for classes and arrays. Although called "type hinting" it does make a type required, as passing an object that does not conform to that type will result in a fatal error.

  • DO specify a type when conformity to a specific interface is an assumption made by the function or method. Specifying the required interface makes debugging easier as passing in a bad value will give a more useful error message.
  • DO NOT use a class as the type in type hinting. If specifying a type, always specify an Interface. That allows other developers to provide their own implementations if necessary without modifying existing code.

PHP supports optional type specification for function and method parameters. Although called "type hinting" it does make a type required, as passing a paramter that does not conform to that type will result in a fatal error.

  • DO specify type hint for all parameter types that support it. This makes debugging easier as passing in a bad value will give a more useful error message.
  • DO NOT use a class as the type in type hinting for objects if an appropriate interface is available. Always specify an Interface. That allows other developers to provide their own implementations if necessary without modifying existing code.

Example:

Remaining tasks

  2. Add supporters
  3. Create a Change Record
  4. Review by the Coding Standards Committee
  5. Coding Standards Committee takes action as required
  6. Discussed by the Core Committer Committee, if it impacts Drupal Core
  7. Final review by Coding Standards Committee
  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 full explanation of these steps see the Coding Standards project page →

📌 Task
Status

Active

Component

Coding Standards

Created by

🇩🇰Denmark johsw

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024