adopt a standard way of documenting service classes

Created on 21 July 2016, over 8 years ago
Updated 14 August 2023, over 1 year ago

I noticed that https://api.drupal.org/api/drupal/core!lib!Drupal!Core!Menu!MenuActiveTr... has as its first docblock line:

> Provides the default implementation of the active menu trail service.

There are a few more service classes with this sort of wording:

$ ag "Provides the default"
core/lib/Drupal/Core/Controller/TitleResolver.php
11: * Provides the default implementation of the title resolver interface.

core/lib/Drupal/Core/Menu/LocalActionManager.php
22: * Provides the default local action manager using YML as primary definition.

core/lib/Drupal/Core/Menu/LocalTaskManager.php
25: * Provides the default local task manager using YML as primary definition.

core/lib/Drupal/Core/Menu/MenuActiveTrail.php
11: * Provides the default implementation of the active menu trail service.

core/lib/Drupal/Core/Site/MaintenanceMode.php
10: * Provides the default implementation of the maintenance mode service.

core/lib/Drupal/Core/Theme/ThemeManager.php
13: * Provides the default implementation of a theme manager.

So I am wondering: should we document all service classes like this?

Furthermore, should that line include the service name, so something like this:

> Provides the default implementation of the menu.active_trail service.

πŸ“Œ Task
Status

Active

Component

Coding Standards

Created by

πŸ‡¬πŸ‡§United Kingdom joachim

Live updates comments and jobs are added and updated live.
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.

  • πŸ‡ΊπŸ‡ΈUnited States Chris Dart

    An additional problem for new developers especially is this: all services should be instantiated with the \Drupal::service() method. Yet if you go to api.drupal.org to look up a service, nothing in the documentation tells what the name of the service's tag is. Somehow this needs to be documented in one place or the other. I recognize that it creates a redundancy and also may violate a theoretical best practice, but without this easily accessible, instantiating a given service amounts to special knowledge which runs contrary to the spirit accessible open-source software.

Production build 0.71.5 2024