Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
With a good self-descriptive API name and a return type, there could be cases where putting the description of a return type would not make sense. For example:
/**
* Determines if series template should be created.
*
* @param array $settings
* Entity bundle settings.
*
* @return bool
* TRUE if yes, otherwise FALSE.
*/
public function shouldCreateSeriesTemplate(array $settings): bool;
Here the the API name itself tells what it would return. Description TRUE if yes, otherwise FALSE. can be skipped - and the purpose of the output could still be understood.
Proposed resolution
Make description optional.
Remaining tasks
N/A
User interface changes
N/A
API changes
N/A
Data model changes
N/A
Release notes snippet
N/A
Comments
Comment #2
subhojit777Comment #3
klausiHm, I interpret the coding standards at https://www.drupal.org/docs/develop/standards/api-documentation-and-comm... so that the return value description is always required. Otherwise it would not make sense to have @return at all: I can already see from the function signature what the type is. It is important to describe what exactly is returned under what circumstances.
So I would leave the @return description in as required by default.
You can disable this specific error in phpcs.xml in your custom projects.