Fact-checked by Grok 2 weeks ago

PHPDoc

PHPDoc is a documentation standard for the PHP programming language, utilizing structured block comments called DocBlocks to annotate and describe code elements such as classes, methods, properties, and functions.^[1] These DocBlocks begin with /** and end with */, allowing developers to include inline descriptions, type information, and metadata tags like @param, @return, @var, and @throws to specify parameters, return values, variable types, and potential exceptions.^[1] The primary purpose of PHPDoc is to enhance code readability for developers while providing machine-readable metadata that tools can parse to generate comprehensive API documentation, including searchable indexes, UML diagrams, and inheritance graphs.^[2] It is maintained as part of the open-source phpDocumentor project, which serves as the de facto tool for processing PHPDoc annotations and producing formatted documentation from PHP source code.^[2] Over more than 20 years of development, PHPDoc has evolved to support modern PHP features, such as union types introduced in PHP 8.0, and remains an informal yet widely adopted standard across PHP projects for its flexibility in documenting complex type systems and inheritance hierarchies via tags like @inheritdoc.^[3]^[2]

Overview

Definition and Purpose

PHPDoc is an informal standard for adding structured comments to PHP source code, primarily through block comments that begin with /**.^[4] This approach allows developers to document classes, functions, methods, properties, and other structural elements in a machine-readable format.^[5] The primary purposes of PHPDoc include enabling the automatic generation of documentation from source code using tools like phpDocumentor, supplying metadata to integrated development environments (IDEs) for features such as auto-completion and type hinting, and providing consistent documentation support for both procedural and object-oriented PHP code.^[6] By embedding descriptive summaries, detailed explanations, and tagged metadata directly in the code, PHPDoc enhances the overall utility of PHP projects without altering their functionality.^[5] Key benefits encompass improved code maintainability via explicit type declarations and functional descriptions that aid future modifications, facilitation of team collaboration through standardized annotations for authorship and version history, and seamless integration with static analysis tools like PHPStan to detect potential errors early in development.^[4] PHPDoc originated as an adaptation of Javadoc concepts, customized to align with PHP's syntax and ecosystem needs.^[5]

Relationship to Other Standards

PHPDoc is directly adapted from Javadoc, the documentation tool developed by Sun Microsystems in 1995 for the Java programming language, adopting a similar tag-based structure for generating API documentation from source code comments while accommodating PHP's dynamic typing and absence of native type annotations.^[7]^[8] PHPDoc integrates with the PHP Framework Interoperability Group (PHP-FIG) standards, particularly through the proposed PSR-5, which aims to provide a complete formal definition of PHPDoc syntax and tags and was initially proposed in 2013 but remains in draft status as of 2025.^[9]^[10] Recent developments include pull requests proposing enhancements like inline tag support within descriptions.^[11] PSR-1, the basic coding standard, does not specify PHPDoc usage but establishes foundational naming and structure conventions that complement documentation practices, while PSR-12, the extended coding style guide, explicitly defines the placement of docblocks, such as requiring file-level docblocks immediately after the opening PHP tag and class-level docblocks before class declarations, to ensure consistent formatting and readability.^[12]^[13] PHPDoc maintains compatibility with project-specific guidelines, such as WordPress's customized documentation standards, which build on PHPDoc tags like @since, @param, and @return but adapt them for WordPress conventions, including version numbering and hook documentation; WordPress plans to deprecate certain tags, such as @subpackage, once PSR-5 is finalized, continuing their use for consistency in the interim.^[14] Similarly, frameworks like Laravel extend PHPDoc with additional tags, such as @mixin for documenting delegated properties in Eloquent models, enhancing IDE support and static analysis without altering the core syntax.^[15] In its evolution toward formalization, PHPDoc aligns with PHP 8+ features like attributes, which introduce native, structured metadata for runtime use and can supplant some PHPDoc-based annotations for type hinting and validation, yet PHPDoc persists as the primary mechanism for generating human-readable documentation and supporting static analysis tools.^[16]^[17]

History

Origins and Early Development

PHPDoc originated in the early 2000s through the creation of phpDocumentor, a documentation generation tool developed by Joshua Eichorn and initially released as a PEAR package in 2003 to produce HTML output from specially formatted comments in PHP source code.^[18]^[19] The tool addressed a notable gap in PHP's ecosystem at the time, where no native mechanism existed for generating structured, automated documentation similar to those available in other languages. Eichorn's project began with a focus on parsing inline comments to extract descriptions, parameters, and return values, laying the groundwork for what would become the PHPDoc standard.^[20] Directly inspired by JavaDoc, phpDocumentor filled this void by adapting a similar block-comment format for PHP, with its first public releases appearing in 2003 and supporting foundational tags like @[param](/page/PARAM) for documenting function parameters and @return for specifying output types.^[19]^[21] These early versions emphasized simplicity and compatibility with PHP 4, enabling developers to embed machine-readable annotations directly in code without altering runtime behavior. The project's copyright notices trace back to 2000, indicating preliminary work by Eichorn even before formal distribution.^[22] By the mid-2000s, phpDocumentor gained traction in the PHP community, with adoption in open-source projects and integration into prominent IDEs such as Zend Studio, which bundled the tool starting with version 5.x around 2006 to facilitate on-the-fly documentation generation.^[23] This period marked the emergence of PHPDoc as an informal de facto standard, driven by grassroots usage rather than official PHP group endorsement, particularly as PHP 5's release in 2004 highlighted the need for better code introspection and tooling.^[24] Community feedback during this era refined the tag system, promoting consistency across disparate projects without centralized governance. The phpDocumentor 1.x release series, spanning from initial versions in 2003 to later stable updates through 2011, played a pivotal role in establishing PHPDoc's core conventions, including the DocBlock structure and tag semantics, through ongoing enhancements and contributions from developers like Gregory Beaver.^[25]^[20] These iterations expanded tag support incrementally—adding options for access levels, exceptions, and links—while maintaining backward compatibility, which encouraged widespread experimentation and solidified PHPDoc's position as a community-led documentation practice.

Formalization and Evolution

In 2013, the PHP Framework Interoperability Group (PHP-FIG) established a working group to develop PSR-5, a proposed meta-specification for PHPDoc aimed at standardizing DocBlock structures, tag definitions, and inheritance rules across PHP tools and projects.^[26] This initiative sought to formalize the previously tool-specific conventions into a community-wide standard, with the draft outlining precise syntax for elements like type expressions and contextual inheritance in documentation.^[26] As of 2025, PSR-5 remains in draft status without formal acceptance, reflecting ongoing discussions on compatibility with existing practices. Parallel to these standardization efforts, PHPDoc evolved through updates in the phpDocumentor tool to align with advancing PHP language features. In March 2012, the DocBlox project merged with the phpDocumentor 1.x branch, leading to the phpDocumentor 2.x series, first released in alpha form later that year, which introduced support for PHP 5.3+ syntax elements such as namespaces and closures, enabling more accurate parsing of modern codebases. Subsequent versions in the 3.x series, a complete rewrite with stable release of 3.0 in 2020 and development commencing around 2017, incorporated PHP 7+ capabilities like scalar type declarations in tags such as @param and @return.^[27] Further enhancements in 3.x addressed PHP 8+ innovations, including union types (e.g., int|string) and attributes as complementary documentation mechanisms beyond traditional DocBlocks, with ongoing releases through 2025 adding support for PHP 8.4 features. Community-driven refinements continued through phpDocumentor 3.x releases from 2017 onward, introducing features like Markdown support for richer inline descriptions and improved inheritance handling to propagate documentation across class hierarchies more reliably. These updates influenced major frameworks, with Symfony incorporating extended PHPDoc tags (e.g., @Template for view annotations) in its coding standards and Laravel leveraging custom tags like @method for dynamic method documentation.^[28] Despite these advancements, PHPDoc remains an informal standard, widely adopted in IDEs, static analyzers, and frameworks due to its practicality, yet facing formalization challenges from backward compatibility requirements and inconsistencies in tool implementations.^[2]

Syntax and Structure

DocBlock Format

A DocBlock in PHPDoc is a multi-line comment enclosed by /** at the beginning and */ at the end, used to document structural elements in PHP code such as classes, functions, methods, properties, and constants.^[5] It must be placed immediately before the element it documents, with no intervening code or comments, to ensure proper parsing by documentation tools.^[5] The structure of a DocBlock consists of three main components. First, a short summary provides a concise one-sentence overview of the element, ending with a period followed by a newline or a blank line, and it must be plain text without inline tags or Markdown formatting.^[29] Second, an optional long description follows the summary, offering detailed explanations such as usage examples or algorithms, and it supports GitHub-flavored Markdown for elements like bold text, links, or inline code.^[6] Third, tags provide metadata and begin with @ on new lines after the description, such as @[param](/page/PARAM) for parameters or @[return](/page/Return) for return values.^[5] Placement rules specify that DocBlocks precede the documented element directly; for files, they appear as the first structural element unless overridden.^[1] In object-oriented contexts, child elements can inherit DocBlocks from parents using the @inheritdoc inline tag, allowing reuse while permitting overrides in subclasses.^[6] Formatting conventions emphasize readability and consistency. Each line within the DocBlock starts with an asterisk (*) aligned vertically for indentation, using 4 spaces per level as per general PHP standards.^[13] Line lengths should not exceed 80 characters where possible, with a soft limit of 120 characters, and longer lines split accordingly to maintain clarity in comments.^[13] The following example illustrates a complete DocBlock for a simple function, showing the summary, long description with Markdown, and tag placement:

php
/**
 * Calculates the sum of two numbers.
 *
 * This function adds the provided [int](/page/INT)egers and returns their total.
 * It is useful for basic arithmetic operations in applications.
 *
 * @param [int](/page/INT) $a The first number to add.
 * @param [int](/page/INT) $b The second number to add.
 * @return [int](/page/INT) The sum of $a and $b.
 */
[function](/page/Function) add([int](/page/INT) $a, [int](/page/INT) $b): [int](/page/INT) {
    return $a + $b;
}
```[](https://docs.phpdoc.org/guide/getting-started/what-is-a-docblock.html)

### Inline Tags and Sections

Inline tags in PHPDoc are enclosed in curly braces and embedded directly within the long description of a DocBlock to enhance [readability](/page/Readability) and provide dynamic content, such as hyperlinks or code snippets, without disrupting the text flow. These tags are processed by tools like phpDocumentor, which substitute them with formatted output during documentation generation. Unlike block-level tags that stand alone on new lines, inline tags must appear only in the long description section, not in the summary or other tag areas, to ensure proper parsing.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)

The long description itself supports Markdown formatting for structured content, including bold (**text**), italics (*text*), ordered and unordered lists, and code blocks delimited by triple backticks (```). The summary, which is a concise one-line overview ending in a period followed by a newline or blank line, remains plain text without Markdown or inline tags. A blank line separates the summary from the long description, allowing multi-line expansions for detailed explanations. Special characters in descriptions, such as curly braces or asterisks, are escaped using Markdown conventions (e.g., \{ for literal braces) to prevent misinterpretation by parsers.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)

For maintenance notes, block tags like @todo and @deprecated can be integrated into the DocBlock structure, with their optional descriptions contributing to the overall narrative in the generated documentation. The [@todo](/page/todo) tag flags pending tasks, often with a brief explanation, while [@deprecated](/page/deprecated) marks elements for removal, including version details and rationale, to guide developers on usage. These tags appear in dedicated reports produced by phpDocumentor, aiding project maintenance.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/todo.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html)

PHPDoc supports several inline tags, each with specific syntax for embedding contextual elements. The following table outlines key inline tags, their syntax, and usage:

| Inline Tag | Syntax | Description and Example |
|------------|--------|-------------------------|
| {@link} | {@link [target] [link text]} | Creates a hyperlink to an internal element (e.g., class or method) or external URL; the optional link text overrides the target as display. Example: "Refer to the {@link MyClass::method() [implementation](/page/Implementation)} for details." renders as a clickable "[implementation](/page/Implementation)" linking to the method.[](https://docs.phpdoc.org/guide/references/phpdoc/inline-tags/link.html) |
| {@inheritDoc} | {@inheritDoc} | Imports the long [description](/page/Description) from a [parent](/page/Parent) [class](/page/Class), [interface](/page/Interface), or [trait](/page/Trait) into the current element's documentation, useful for overriding methods. Example: In a [child](/page/Child) [class](/page/Class) method: "Overrides [parent](/page/Parent) behavior. {@inheritDoc}" appends the parent's [description](/page/Description).[](https://docs.phpdoc.org/guide/references/phpdoc/inline-tags/inheritdoc.html) |
| {@internal} | {@internal [description]} | Marks a section of the [description](/page/Description) as internal, visible only to developers (filtered in public output unless specified). Example: "This API is {@internal for extension developers only}." hides the note in standard docs.[](https://docs.phpdoc.org/guide/references/phpdoc/inline-tags/internal.html) |

phpDocumentor parses these tags during processing, substituting them based on context (e.g., resolving {@link} to actual URLs or element references), and supports nesting within other inline tags for complex descriptions. Inline tags enhance interactivity in generated [HTML](/page/HTML) documentation while maintaining PHPDoc's focus on developer tools. Note that older versions of phpDocumentor supported additional inline tags, some of which are no longer standard.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)

### Example DocBlock with Inline Tags and Markdown
/**
 * Calculates the sum of two numbers.
 *
 * This function adds the provided [int](/page/INT)egers and returns their total.
 * It is useful for basic arithmetic operations in applications.
 *
 * @param [int](/page/INT) $a The first number to add.
 * @param [int](/page/INT) $b The second number to add.
 * @return [int](/page/INT) The sum of $a and $b.
 */
[function](/page/Function) add([int](/page/INT) $a, [int](/page/INT) $b): [int](/page/INT) {
    return $a + $b;
}
```[](https://docs.phpdoc.org/guide/getting-started/what-is-a-docblock.html)

### Inline Tags and Sections

Inline tags in PHPDoc are enclosed in curly braces and embedded directly within the long description of a DocBlock to enhance [readability](/page/Readability) and provide dynamic content, such as hyperlinks or code snippets, without disrupting the text flow. These tags are processed by tools like phpDocumentor, which substitute them with formatted output during documentation generation. Unlike block-level tags that stand alone on new lines, inline tags must appear only in the long description section, not in the summary or other tag areas, to ensure proper parsing.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)

The long description itself supports Markdown formatting for structured content, including bold (**text**), italics (*text*), ordered and unordered lists, and code blocks delimited by triple backticks (```). The summary, which is a concise one-line overview ending in a period followed by a newline or blank line, remains plain text without Markdown or inline tags. A blank line separates the summary from the long description, allowing multi-line expansions for detailed explanations. Special characters in descriptions, such as curly braces or asterisks, are escaped using Markdown conventions (e.g., \{ for literal braces) to prevent misinterpretation by parsers.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)

For maintenance notes, block tags like @todo and @deprecated can be integrated into the DocBlock structure, with their optional descriptions contributing to the overall narrative in the generated documentation. The [@todo](/page/todo) tag flags pending tasks, often with a brief explanation, while [@deprecated](/page/deprecated) marks elements for removal, including version details and rationale, to guide developers on usage. These tags appear in dedicated reports produced by phpDocumentor, aiding project maintenance.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/todo.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html)

PHPDoc supports several inline tags, each with specific syntax for embedding contextual elements. The following table outlines key inline tags, their syntax, and usage:

| Inline Tag | Syntax | Description and Example |
|------------|--------|-------------------------|
| {@link} | {@link [target] [link text]} | Creates a hyperlink to an internal element (e.g., class or method) or external URL; the optional link text overrides the target as display. Example: "Refer to the {@link MyClass::method() [implementation](/page/Implementation)} for details." renders as a clickable "[implementation](/page/Implementation)" linking to the method.[](https://docs.phpdoc.org/guide/references/phpdoc/inline-tags/link.html) |
| {@inheritDoc} | {@inheritDoc} | Imports the long [description](/page/Description) from a [parent](/page/Parent) [class](/page/Class), [interface](/page/Interface), or [trait](/page/Trait) into the current element's documentation, useful for overriding methods. Example: In a [child](/page/Child) [class](/page/Class) method: "Overrides [parent](/page/Parent) behavior. {@inheritDoc}" appends the parent's [description](/page/Description).[](https://docs.phpdoc.org/guide/references/phpdoc/inline-tags/inheritdoc.html) |
| {@internal} | {@internal [description]} | Marks a section of the [description](/page/Description) as internal, visible only to developers (filtered in public output unless specified). Example: "This API is {@internal for extension developers only}." hides the note in standard docs.[](https://docs.phpdoc.org/guide/references/phpdoc/inline-tags/internal.html) |

phpDocumentor parses these tags during processing, substituting them based on context (e.g., resolving {@link} to actual URLs or element references), and supports nesting within other inline tags for complex descriptions. Inline tags enhance interactivity in generated [HTML](/page/HTML) documentation while maintaining PHPDoc's focus on developer tools. Note that older versions of phpDocumentor supported additional inline tags, some of which are no longer standard.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)

### Example DocBlock with Inline Tags and Markdown

/**

Processes user input securely.
This method validates and sanitizes data before storage. For detailed validation rules,
see the {@link Validator::rules()} method.
Usage
- Call with raw input: $processed = $this->sanitize($input);
- Handles arrays and scalars.
@todo Implement support for nested objects in v2.0.
@deprecated 1.5.0 Use {@link SecureProcessor::handle()} instead.
@return string Sanitized output. */


In this example, the long description uses [Markdown](/page/Markdown) for bold and headings, incorporates {@link} for internal [reference](/page/Reference), and includes [block](/page/Block) tags for [maintenance](/page/Maintenance) notes, demonstrating integrated inline and sectional elements.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/todo.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html)

## Tags

### General-Purpose Tags

General-purpose tags in PHPDoc provide [metadata](/page/Metadata) applicable to various structural elements such as classes, functions, properties, and files, facilitating authorship attribution, versioning, licensing, and [maintenance](/page/Maintenance) notes without being specific to parameters or returns. These tags enhance documentation readability and tool integration, allowing [IDEs](/page/Ides) and generators like phpDocumentor to extract and display relevant information. They are placed within DocBlocks and can often be inherited from [parent](/page/Parent) elements in class hierarchies, promoting consistency across object-oriented codebases.

Core tags focus on authorship and legal aspects. The `@author` tag documents the creator or significant contributor of an element, supporting multiple instances for collaborative works; its syntax is `@author [name] [<email>]`, where the email follows RFC 5322 or 2822 standards for linking in generated docs.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/author.html) The `@version` tag specifies the current release using Semantic Versioning 2.0, with syntax `@version [<version>] [<description>]`; it is typically used once per element to indicate maturity, distinct from introduction timing.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/version.html) The `@copyright` tag denotes ownership details, formatted as `@copyright [year] [holder]`, and allows multiple entries for evolving copyrights over time.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/copyright.html) Similarly, the `@license` tag declares licensing terms, using `@license [URI|text]`, often once but extensible for multiple licenses if applicable. The `@since` tag marks the version or date of an element's introduction, with syntax `@since [version|date]`, applied singly to track evolution.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/since.html)

Structural tags organize documentation hierarchically. The `@package` tag groups related elements into namespaces, using `@package [name]` once per element or file to define broad categories; hierarchical sub-grouping can be achieved with backslashes, e.g., `@package Package\Subpackage`.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/package.html) The `@subpackage` tag, formatted as `@subpackage [name]` and used singly, refines grouping within a package but is deprecated; multi-level `@package` tags are recommended instead.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/subpackage.html) The `@category` tag, with `@category [name]` used once, provides high-level classification to aggregate packages thematically but is deprecated; use `@package` for such organization in modern tools.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/category.html) The `@internal` tag signals private implementation details not intended for external use, via `@internal [text]`, applied once to suppress or warn in public docs.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/internal.html)

Maintenance tags aid ongoing development. The `@todo` tag lists pending tasks, allowing multiples with `@todo [description]` to flag incomplete features or fixes. The `@deprecated` tag warns of impending removal, using `@deprecated [version] [description]` once to specify the deprecation point and alternatives.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html) The `@link` tag creates hyperlinks to external or internal resources, supporting multiples via `@link [URL] [description]` for cross-references.

Usage rules emphasize flexibility: tags like `@author`, `@copyright`, `@todo`, and `@link` permit multiple instances, while others such as `@version`, `@since`, `@package`, `@subpackage`, `@category`, `@internal`, and `@deprecated` are typically singular to avoid redundancy. In [class](/page/Class) and [method](/page/Method) DocBlocks, these tags inherit from parents unless overridden, enabling centralized [metadata](/page/Metadata) in [inheritance](/page/Inheritance) chains.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html) For instance, a deprecated method might use:

In this example, the long description uses [Markdown](/page/Markdown) for bold and headings, incorporates {@link} for internal [reference](/page/Reference), and includes [block](/page/Block) tags for [maintenance](/page/Maintenance) notes, demonstrating integrated inline and sectional elements.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/todo.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html)

## Tags

### General-Purpose Tags

General-purpose tags in PHPDoc provide [metadata](/page/Metadata) applicable to various structural elements such as classes, functions, properties, and files, facilitating authorship attribution, versioning, licensing, and [maintenance](/page/Maintenance) notes without being specific to parameters or returns. These tags enhance documentation readability and tool integration, allowing [IDEs](/page/Ides) and generators like phpDocumentor to extract and display relevant information. They are placed within DocBlocks and can often be inherited from [parent](/page/Parent) elements in class hierarchies, promoting consistency across object-oriented codebases.

Core tags focus on authorship and legal aspects. The `@author` tag documents the creator or significant contributor of an element, supporting multiple instances for collaborative works; its syntax is `@author [name] [<email>]`, where the email follows RFC 5322 or 2822 standards for linking in generated docs.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/author.html) The `@version` tag specifies the current release using Semantic Versioning 2.0, with syntax `@version [<version>] [<description>]`; it is typically used once per element to indicate maturity, distinct from introduction timing.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/version.html) The `@copyright` tag denotes ownership details, formatted as `@copyright [year] [holder]`, and allows multiple entries for evolving copyrights over time.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/copyright.html) Similarly, the `@license` tag declares licensing terms, using `@license [URI|text]`, often once but extensible for multiple licenses if applicable. The `@since` tag marks the version or date of an element's introduction, with syntax `@since [version|date]`, applied singly to track evolution.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/since.html)

Structural tags organize documentation hierarchically. The `@package` tag groups related elements into namespaces, using `@package [name]` once per element or file to define broad categories; hierarchical sub-grouping can be achieved with backslashes, e.g., `@package Package\Subpackage`.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/package.html) The `@subpackage` tag, formatted as `@subpackage [name]` and used singly, refines grouping within a package but is deprecated; multi-level `@package` tags are recommended instead.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/subpackage.html) The `@category` tag, with `@category [name]` used once, provides high-level classification to aggregate packages thematically but is deprecated; use `@package` for such organization in modern tools.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/category.html) The `@internal` tag signals private implementation details not intended for external use, via `@internal [text]`, applied once to suppress or warn in public docs.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/internal.html)

Maintenance tags aid ongoing development. The `@todo` tag lists pending tasks, allowing multiples with `@todo [description]` to flag incomplete features or fixes. The `@deprecated` tag warns of impending removal, using `@deprecated [version] [description]` once to specify the deprecation point and alternatives.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html) The `@link` tag creates hyperlinks to external or internal resources, supporting multiples via `@link [URL] [description]` for cross-references.

Usage rules emphasize flexibility: tags like `@author`, `@copyright`, `@todo`, and `@link` permit multiple instances, while others such as `@version`, `@since`, `@package`, `@subpackage`, `@category`, `@internal`, and `@deprecated` are typically singular to avoid redundancy. In [class](/page/Class) and [method](/page/Method) DocBlocks, these tags inherit from parents unless overridden, enabling centralized [metadata](/page/Metadata) in [inheritance](/page/Inheritance) chains.[](https://docs.phpdoc.org/guide/references/phpdoc/basic-syntax.html) For instance, a deprecated method might use:

/**

@author Jane Doe [email protected]
@version 2.1.0
@deprecated 2.0.0 Use calculateNewMethod() instead. / public function oldCalculate() { / ... */ }


This example attributes authorship, notes the current [version](/page/Version), and alerts users to [deprecation](/page/Deprecation), all inheritable if in a subclass.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/author.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/version.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html)

### Parameter and Return Tags

PHPDoc provides specific tags to document the inputs and outputs of functions and methods, enabling clear specification of [parameter](/page/Parameter) types, [return](/page/Return) values, and potential exceptions. The [@param](/page/param) tag is used to describe individual arguments in a [function](/page/Function) or [method](/page/Method) [signature](/page/Signature), including their types and purposes. Its syntax is `@param [<Type>] [...]$[name] [<description>]`, where the type can be a scalar, [class](/page/Class) name, or compound type, the [ellipsis](/page/Ellipsis) (`...`) indicates variadic [parameters](/page/Parameter), and the description provides context on usage or constraints.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/param.html) [Union](/page/Union) types, such as `int|[string](/page/String)`, are supported to reflect PHP 8+ capabilities, while optional [parameters](/page/Parameter) are denoted by default values in the code or explicit mentions in the description.[](https://docs.phpdoc.org/guide/references/phpdoc/types.html) For properties and constants, the [@var](/page/Var) tag documents their types and values, with syntax `@var [Type] [element name] [<description>]`; it is particularly useful when the type is ambiguous or not declared in the code.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/var.html)

The @return tag specifies the type and nature of a function or method's output, using the syntax `@return [Type] [<description>]`. Common types include `void` for no return, `mixed` for unspecified values, and complex structures like `array<string, int>` or `iterable` for collections.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/return.html) Descriptions enhance clarity, especially for associative arrays or conditional logic. While the standard allows only one @return tag per DocBlock, tools like PHPStan support conditional expressions within it, such as `@return ($flag ? string : int)` for branches based on parameters.[](https://phpstan.org/blog/phpstan-1-6-0-with-conditional-return-types) PHPDoc type support has evolved with PHP versions: scalars like `int` and `bool` were formalized in PHP 7+, and union types with the pipe operator (`|`) in PHP 8+.[](https://docs.phpdoc.org/guide/references/phpdoc/types.html)

To indicate potential errors, the @throws tag documents exceptions or errors a function might raise, with syntax `@throws [Type] [<description>]`, where the type must implement the Throwable interface (e.g., `InvalidArgumentException`). The description should explain the triggering condition, such as invalid input validation. Multiple @throws tags can be used to cover various scenarios.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/throws.html)

For advanced documentation of dynamic elements, PHPDoc includes tags for magic methods and properties enabled by PHP's overloading features. The @method tag describes callable methods via `__call()` or `__callStatic()`, using syntax `@method [[static] return type] [name]([[type] [parameter]<, ...>]) [<description>]`; it allows specifying argument types and return values for non-literal methods.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/method.html) Similarly, @property, along with @property-read and @property-write variants, documents dynamic properties accessed through `__get()` or `__set()`, with syntax `@property[<-read|-write>] [Type] [name] [<description>]`; these are essential for classes implementing property overloading.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/property.html)

Parameters documented with @param must appear in the same order as in the function signature, and all such tags are recommended—especially required—for public APIs to ensure accurate tooling support and code readability. The following example illustrates a complete method DocBlock incorporating these tags:

```php
/**
 * Processes user input and returns a formatted result.
 *
 * @param [string](/page/String) $input The raw [string](/page/String) to process.
 * @param int|[float](/page/Float) $threshold Optional threshold value, defaults to 0.5.
 * @param [string](/page/String) ...$options Additional variadic options for customization.
 * @return [array](/page/Array)<[string](/page/String), mixed> An [associative array](/page/Associative_array) with processed data.
 * @throws InvalidArgumentException If $input is empty or invalid.
 * @throws RuntimeException On processing failure due to resource limits.
 */
[public](/page/Public) [function](/page/Function) processInput([string](/page/String) $input, [float](/page/Float) $threshold = 0.5, ...$options): [array](/page/Array)
{
    // Implementation...
}

This example attributes authorship, notes the current [version](/page/Version), and alerts users to [deprecation](/page/Deprecation), all inheritable if in a subclass.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/author.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/version.html)[](https://docs.phpdoc.org/guide/references/phpdoc/tags/deprecated.html)

### Parameter and Return Tags

PHPDoc provides specific tags to document the inputs and outputs of functions and methods, enabling clear specification of [parameter](/page/Parameter) types, [return](/page/Return) values, and potential exceptions. The [@param](/page/param) tag is used to describe individual arguments in a [function](/page/Function) or [method](/page/Method) [signature](/page/Signature), including their types and purposes. Its syntax is `@param [<Type>] [...]$[name] [<description>]`, where the type can be a scalar, [class](/page/Class) name, or compound type, the [ellipsis](/page/Ellipsis) (`...`) indicates variadic [parameters](/page/Parameter), and the description provides context on usage or constraints.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/param.html) [Union](/page/Union) types, such as `int|[string](/page/String)`, are supported to reflect PHP 8+ capabilities, while optional [parameters](/page/Parameter) are denoted by default values in the code or explicit mentions in the description.[](https://docs.phpdoc.org/guide/references/phpdoc/types.html) For properties and constants, the [@var](/page/Var) tag documents their types and values, with syntax `@var [Type] [element name] [<description>]`; it is particularly useful when the type is ambiguous or not declared in the code.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/var.html)

The @return tag specifies the type and nature of a function or method's output, using the syntax `@return [Type] [<description>]`. Common types include `void` for no return, `mixed` for unspecified values, and complex structures like `array<string, int>` or `iterable` for collections.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/return.html) Descriptions enhance clarity, especially for associative arrays or conditional logic. While the standard allows only one @return tag per DocBlock, tools like PHPStan support conditional expressions within it, such as `@return ($flag ? string : int)` for branches based on parameters.[](https://phpstan.org/blog/phpstan-1-6-0-with-conditional-return-types) PHPDoc type support has evolved with PHP versions: scalars like `int` and `bool` were formalized in PHP 7+, and union types with the pipe operator (`|`) in PHP 8+.[](https://docs.phpdoc.org/guide/references/phpdoc/types.html)

To indicate potential errors, the @throws tag documents exceptions or errors a function might raise, with syntax `@throws [Type] [<description>]`, where the type must implement the Throwable interface (e.g., `InvalidArgumentException`). The description should explain the triggering condition, such as invalid input validation. Multiple @throws tags can be used to cover various scenarios.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/throws.html)

For advanced documentation of dynamic elements, PHPDoc includes tags for magic methods and properties enabled by PHP's overloading features. The @method tag describes callable methods via `__call()` or `__callStatic()`, using syntax `@method [[static] return type] [name]([[type] [parameter]<, ...>]) [<description>]`; it allows specifying argument types and return values for non-literal methods.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/method.html) Similarly, @property, along with @property-read and @property-write variants, documents dynamic properties accessed through `__get()` or `__set()`, with syntax `@property[<-read|-write>] [Type] [name] [<description>]`; these are essential for classes implementing property overloading.[](https://docs.phpdoc.org/guide/references/phpdoc/tags/property.html)

Parameters documented with @param must appear in the same order as in the function signature, and all such tags are recommended—especially required—for public APIs to ensure accurate tooling support and code readability. The following example illustrates a complete method DocBlock incorporating these tags:

```php
/**
 * Processes user input and returns a formatted result.
 *
 * @param [string](/page/String) $input The raw [string](/page/String) to process.
 * @param int|[float](/page/Float) $threshold Optional threshold value, defaults to 0.5.
 * @param [string](/page/String) ...$options Additional variadic options for customization.
 * @return [array](/page/Array)<[string](/page/String), mixed> An [associative array](/page/Associative_array) with processed data.
 * @throws InvalidArgumentException If $input is empty or invalid.
 * @throws RuntimeException On processing failure due to resource limits.
 */
[public](/page/Public) [function](/page/Function) processInput([string](/page/String) $input, [float](/page/Float) $threshold = 0.5, ...$options): [array](/page/Array)
{
    // Implementation...
}

This structure promotes type safety and aids static analysis tools without altering runtime behavior.^[30]^[31]^[32]

Usage

Documenting Functions and Methods

PHPDoc documentation for functions is provided through a DocBlock placed immediately before the function declaration, consisting of a summary line, an optional extended description, and relevant tags such as @param for parameters and @return for the return value. The summary offers a concise one-liner purpose, while the description can elaborate on usage, side effects, or performance implications using Markdown for readability. The @param tag specifies the type, name, and intent of each argument, particularly useful when PHP type hints are absent or insufficient, with syntax @param [Type] $[name] [<description>]. Similarly, the @return tag documents the output with @return [Type] [<description>], omitting it for void returns or implying @return self for constructors. For functions interacting with global variables, the @global tag declares their type and usage, using syntax @global [Type] [name] [<description>] without a dollar sign prefix in the name.^[29]^[30]^[31]^[33] A procedural function example demonstrates this structure:

php
/**
 * Counts the number of items in an [array](/page/Array), optionally recursively.
 *
 * This [function](/page/Function) processes arrays and may modify [global](/page/Global) counters if enabled.
 * For large arrays, consider performance impacts from [recursion](/page/Recursion) depth.
 *
 * @param mixed[] $items The [array](/page/Array) to count.
 * @param bool $recursive Whether to count recursively; defaults to false.
 * @global int total_count Increments a [global](/page/Global) tally of processed items.
 * @return int The total number of elements found.
 */
[function](/page/Function) countItems([array](/page/Array) $items, bool $recursive = false): [int](/page/INT) {
    [global](/page/Global) $total_count;
    $count = [count](/page/Count)($items);
    $total_count += $count;
    if ($recursive) {
        // Recursive logic here
    }
    [return](/page/Return) $count;
}
/**
 * Counts the number of items in an [array](/page/Array), optionally recursively.
 *
 * This [function](/page/Function) processes arrays and may modify [global](/page/Global) counters if enabled.
 * For large arrays, consider performance impacts from [recursion](/page/Recursion) depth.
 *
 * @param mixed[] $items The [array](/page/Array) to count.
 * @param bool $recursive Whether to count recursively; defaults to false.
 * @global int total_count Increments a [global](/page/Global) tally of processed items.
 * @return int The total number of elements found.
 */
[function](/page/Function) countItems([array](/page/Array) $items, bool $recursive = false): [int](/page/INT) {
    [global](/page/Global) $total_count;
    $count = [count](/page/Count)($items);
    $total_count += $count;
    if ($recursive) {
        // Recursive logic here
    }
    [return](/page/Return) $count;
}

This example includes a description noting potential side effects via the global and performance considerations, aligning with recommendations to detail non-obvious behaviors beyond tags.^[29]^[30]^[31]^[33] For methods within classes, interfaces, or traits, DocBlocks follow the same format but are placed before the method signature, inheriting tags like @param and @return from parent elements unless overridden. Visibility can be implied by the code's access modifiers, though older @access tags are deprecated in favor of native PHP syntax. When overriding methods, the inline tag {@inheritdoc} imports the parent's description or specific tags, allowing augmentation without full repetition; for instance, placing {@inheritdoc} in the summary or description pulls from the inherited element. Static methods support types like self::$property for class properties or static for return values indicating late static binding, where the method returns an instance of the invoking subclass rather than the defining class.^[29]^[34]^[35] Constructors and destructors are documented as standard methods, with constructors typically omitting @return (implying @return self or the class instance) and focusing on @param for initialization arguments; destructors, lacking returns, use descriptions to note cleanup side effects. Best practices emphasize including side effects (e.g., resource allocation) and performance notes in the description, while ensuring PHPDoc types complement rather than duplicate PHP 7+ type hints for consistency. Common pitfalls include redundant documentation when native types suffice, leading to maintenance overhead, and type-tag misalignment with actual code, which can confuse tools like phpDocumentor or IDEs; always verify tags against implementation to avoid such discrepancies.^[31]^[29]^[35] A complete class method example illustrates these elements:

php
class ExampleClass {
    /**
     * Constructs a new instance with optional configuration.
     *
     * Initializes properties and may connect to external resources,
     * potentially impacting startup time in high-load scenarios.
     *
     * @param string $config The configuration string.
     * @return self
     */
    public function __construct(string $config) {
        // Initialization logic
    }

    /**
     * Retrieves a value, supporting static calls via late binding.
     *
     * @param string $key The key to retrieve.
     * @return static The value or subclass instance if static call.
     */
    public static function getValue(string $key) {
        // Retrieval logic
        return new static();
    }

    /**
     * Overrides parent method to add validation.
     *
     * {@inheritdoc}
     * Additional validation ensures input safety.
     *
     * @param int $input Validated integer input.
     * @return bool Success indicator.
     */
    public function process(int $input): bool {
        // Overridden logic
        return true;
    }
}
class ExampleClass {
    /**
     * Constructs a new instance with optional configuration.
     *
     * Initializes properties and may connect to external resources,
     * potentially impacting startup time in high-load scenarios.
     *
     * @param string $config The configuration string.
     * @return self
     */
    public function __construct(string $config) {
        // Initialization logic
    }

    /**
     * Retrieves a value, supporting static calls via late binding.
     *
     * @param string $key The key to retrieve.
     * @return static The value or subclass instance if static call.
     */
    public static function getValue(string $key) {
        // Retrieval logic
        return new static();
    }

    /**
     * Overrides parent method to add validation.
     *
     * {@inheritdoc}
     * Additional validation ensures input safety.
     *
     * @param int $input Validated integer input.
     * @return bool Success indicator.
     */
    public function process(int $input): bool {
        // Overridden logic
        return true;
    }
}

This example shows inheritance via {@inheritdoc}, static typing, and constructor handling, promoting clear, tool-compatible documentation.^[29]^[34]^[30]^[31]^[35]

Documenting Classes and Properties

PHPDoc documentation for classes begins with a DocBlock placed immediately above the class declaration, providing a summary description of the class's purpose and functionality. This DocBlock can include inline tags for additional details and specific tags such as @package and @author for contextual information. For interfaces, the DocBlock similarly describes the contract that implementing classes must fulfill, while for traits, it outlines the reusable code components intended for composition into classes. phpDocumentor automatically detects inheritance relationships from PHP code, such as extends for classes and implements for interfaces, but developers can enhance clarity by referencing them in the description if needed.^[5]^[34] Abstract classes are documented through their DocBlock, emphasizing that they cannot be instantiated and serve as base classes requiring extension, with the abstract keyword in PHP code indicating this structure. The description should highlight methods or properties that subclasses must override or implement. Traits, introduced in PHP 5.4, follow the same DocBlock format as classes, focusing on the shared behaviors they provide without direct inheritance notation, as phpDocumentor infers trait usage from the using statement in classes.^[34]^[36] Properties are documented using the @var tag in a DocBlock immediately preceding the property declaration, specifying the type, variable name, and an optional description. The syntax is @var Type $propertyName [description], where Type can include PHP primitives, class names, or compound types like unions (e.g., string|int|null). For PHP 8.1 and later, readonly properties declared with the readonly keyword are recognized by phpDocumentor through code parsing. The @var tag specifies the type and description, e.g., @var string $immutableProp.^[37]^[38]^[39] For dynamic or magic properties accessed via __get() or __set() methods, the @property tag is used within the class's DocBlock to declare them explicitly. The syntax is @property[<-read|-write>] Type $propertyName [description], where @property indicates bidirectional access, @property-read for read-only, and @property-write for write-only. This ensures these non-literal properties appear in generated documentation without generating actual code variables.^[40] Class constants are documented similarly with the @var tag above the constant declaration, using immutable types to reflect their fixed nature, such as @var [int](/page/INT) MAX_VALUE. The tag specifies the type and name, with phpDocumentor linking it appropriately in output.^[37] In inheritance scenarios, child classes, interfaces, or traits inherit the parent's DocBlock summary, long description, and certain tags (e.g., @author, @version) unless overridden. The inline tag {@inheritdoc} can be placed in the child's description to explicitly import and append the parent's content, allowing documentation of overrides or changes, such as altered property behaviors. For properties and constants in subclasses, redeclaration with @var updates the inherited details if modified.^[34] The following example illustrates a class with a DocBlock, readonly property, constant, and magic property:

php
/**
 * A sample class representing a user profile.
 *
 * This class manages user data with immutable identifiers.
 *
 * @package MyApp\User
 * @author Developer Name
 */
class UserProfile
{
    /**
     * @var string $id
     * Unique identifier for the user, set once at creation.
     */
    public readonly string $id;

    /**
     * @var int DEFAULT_TIMEOUT
     * Default session timeout in seconds.
     */
    public const DEFAULT_TIMEOUT = 30;

    /**
     * @property-read string $fullName
     * Computed full name from first and last names via __get().
     */
    // Magic property handled in __get()

    public function __construct(string $id)
    {
        $this->id = $id;
    }
}
/**
 * A sample class representing a user profile.
 *
 * This class manages user data with immutable identifiers.
 *
 * @package MyApp\User
 * @author Developer Name
 */
class UserProfile
{
    /**
     * @var string $id
     * Unique identifier for the user, set once at creation.
     */
    public readonly string $id;

    /**
     * @var int DEFAULT_TIMEOUT
     * Default session timeout in seconds.
     */
    public const DEFAULT_TIMEOUT = 30;

    /**
     * @property-read string $fullName
     * Computed full name from first and last names via __get().
     */
    // Magic property handled in __get()

    public function __construct(string $id)
    {
        $this->id = $id;
    }
}

This structure ensures comprehensive documentation of declarative elements like classes and fields.^[37]^[40]^[34]

Tools and Integration

Documentation Generators

Documentation generators are tools that analyze PHP source code and PHPDoc comments to produce structured, readable documentation outputs, such as HTML websites or other formats, facilitating API reference and code comprehension.^[7] The primary tool for this purpose is phpDocumentor, an open-source, command-line interface (CLI)-based application that has served as the de facto standard for PHP documentation generation since its inception over 20 years ago.^[2] In its current versions (3.x and later), phpDocumentor supports customizable templates for outputs including HTML and PDF, allowing users to generate comprehensive API documentation directly from source code files containing PHPDoc annotations.^[41]^[42] Configuration is handled through a phpdoc.xml file, which defines paths, versions, settings, and template options in an XML structure validated against an XSD schema.^[43] Alternatives to phpDocumentor include ApiGen, a modern, lightweight successor tool that emphasizes speed and simplicity while supporting all features up to PHP 8.3, making it suitable for generating professional API documentation from PHPDoc comments.^[44] DocBlox, originally a fork of phpDocumentor version 2 focused on enhanced PHP 5.3 compatibility and additional features, was later merged back into the main phpDocumentor project, rendering it largely historical though still referenced in legacy contexts.^[45] Framework-specific tools, such as Symfony's PropertyInfo component's DoctrineExtractor, provide targeted extraction of PHPDoc-based metadata (e.g., property types from annotations) for integration into larger systems, though they are not full-fledged documentation generators.^[46] Key features of these generators include cross-referencing of elements for navigation between related code parts, integrated search functionality, and visual inheritance graphs often powered by tools like GraphViz to illustrate class hierarchies.^[2] They also handle modern PHP constructs such as namespaces and PSR-4 autoloading standards, enabling accurate documentation of namespaced code without manual path adjustments.^[47] The typical usage process begins with installation via Composer as a development dependency: composer require --dev phpdocumentor/phpdocumentor. Documentation is then generated using CLI commands, such as phpdoc run -d src -t docs to scan the src directory and output to a docs folder; customization occurs via the phpdoc.xml file for specifying themes, excluding files or directories (e.g., via glob patterns like tests/**/*), and setting cache locations to improve subsequent runs.^[48]^[43] Despite their utility, these tools rely heavily on well-formed PHPDoc comments for accurate output, where incomplete or malformed annotations can lead to gaps in the generated documentation.^[5] Performance challenges arise on large codebases, potentially causing hangs or excessive processing time during parsing and rendering, as reported in community issues with projects exceeding thousands of files.^[49]

IDE and Editor Support

PhpStorm, developed by JetBrains, provides comprehensive support for PHPDoc, including automatic generation of docblocks, validation of tags against official standards, and integration with refactoring tools that leverage annotations for safe code changes.^[50] It renders PHPDoc comments in the editor for improved readability and supports all standard PHPDoc tags, along with extensions for advanced type annotations.^[51] For instance, PhpStorm infers types from @param and @return tags to enable precise auto-completion and error detection in dynamically typed PHP code.^[52] Zend Studio, a legacy enterprise-focused IDE from Zend Technologies (last updated in 2017), supports PHP up to version 7.1 and offers built-in PHPDoc generation, syntax highlighting within comments, and code completion for tags and variables, facilitating documentation in legacy PHP projects.^[53] It allows users to generate full documentation sets directly from source code while validating annotations for consistency.^[54] In Visual Studio Code, extensions such as PHP Intelephense provide advanced PHPDoc parsing, including support for templates and callable signatures, which enhances type inference and suggestions.^[55] The PHP DocBlocker extension automates docblock creation for functions and classes, streamlining the documentation process during development.^[56] For lightweight editors, Vim plugins like those in the php.vim suite enable PHPDoc snippet insertion and generation, allowing developers to quickly add structured comments via keybindings.^[57] Sublime Text's PhpDoc package supports tag completion and formatting, integrating seamlessly with PHP workflows for faster annotation entry.^[58] Emacs users can leverage php-mode with additional packages for basic PHPDoc support, though it focuses more on snippet-based insertion than full validation. Common features across these tools include auto-completion derived from @param and @return tags, which helps predict method signatures; type inference that bridges PHP's dynamic nature by treating annotations as hints for static analysis; and error highlighting for discrepancies, such as mismatched parameter types in docblocks versus code.^[52]^[55] Navigation aids like the @link tag enable quick jumps to referenced elements, improving code exploration in complex projects.^[50] Deeper integrations often align with PSR-5 drafts, incorporating proposed standards for extended PHPDoc syntax, and allow custom templates for organization-specific tag formats.^[10] In large projects, PHPDoc annotations support refactoring by preserving type information during renames or extractions, reducing errors in team environments.^[52] By 2025, PHPDoc integration is widespread among PHP developers, with major IDEs like PhpStorm and Visual Studio Code adopted by a significant portion of the community, as evidenced by usage trends in developer surveys.^[59]

References

[1]
PHPDoc reference - DocBlock - phpDocumentor
PHPDoc reference. Basic Syntax · What is a DocBlock? Which elements can have a DocBlock · Sections · Inheritance · Definition of a 'Type'.
[2]
phpDocumentor: Home
phpDocumentor is the de-facto documentation application for PHP projects. Your project can benefit too from more than 20 years of experience.Documentation · Installation · Components · Getting started<|control11|><|separator|>
[3]
Supported Types - phpDocumentor
The PHPDoc Standard, and thus phpDocumentor, can refer to all primitive types in PHP. ... PHP 8.0 has added native support for union types, see the php ...
[4]
PHP: The Right Way | Reference for PHP best practices
PHPDoc. PHPDoc is an informal standard for commenting PHP code. There are a lot of different tags available. The full list of tags and examples can be found ...
[5]
What is a DocBlock? - phpDocumentor
A DocBlock is a piece of documentation in your source code that informs you what the function of a certain class, method or other Structural Element is.
[6]
More on DocBlocks - phpDocumentor
Using a DocBlock you are able to effectively document your application's API (Application Programming Interface) by describing the function of, and relations ...Missing: benefits maintainability collaboration static<|control11|><|separator|>
[7]
Documentation - phpDocumentor
phpDocumentor is the de-facto documentation application for PHP projects. Your project can benefit too from more than 20 years of experience.
[8]
API documentation from source code comments - ACM Digital Library
API documentation from source code comments: a case study of Javadoc. Author: Douglas Kramer. Douglas Kramer. Sun Microsystems, Inc., Palo Alto, CA ... 1995 ...
[9]
Updates from PHP-FIG: February and March
Apr 3, 2018 · PSR-5: PHPDoc take two. As we said in the last update, we are in the process of recovering PSR-5, the proposed standard for PHPDoc. Chuck ...Missing: date | Show results with:date
[10]
PSR-1: Basic Coding Standard - PHP-FIG
### Summary: How PSR-1 Relates to PHPDoc or Comments
[11]
PSR-12: Extended Coding Style - PHP-FIG
This specification extends, expands and replaces PSR-2, the coding style guide and requires adherence to PSR-1, the basic coding standard.
[12]
PHP Documentation Standards - WordPress Developer Resources
Apr 25, 2019 · WordPress uses a customized documentation schema that draws inspiration from PHPDoc, an evolving standard for providing documentation to PHP code.
[13]
PHPDoc annotations - PHP autodoc
@mixin. Use this tag to specify that some property types of this class are being delegated to another class. This tag is useful when using Laravel Eloquent API ...
[14]
Attributes overview - Manual - PHP
PHP attributes provide structured, machine-readable metadata for classes, methods, functions, parameters, properties, and constants.
[15]
Adoption of PHP 8 attributes in 2022 - Exakat
May 18, 2022 · PHP 8 introduced the attributes, in lieu of the phpdoc comments. They may be added to classes, methods, functions, parameters, properties and class constants.
[16]
PhpDocumentor
### Release History for PhpDocumentor 1.x Versions
[17]
pear/PhpDocumentor - GitHub
pear.php.net/package/PhpDocumentor. License. View license · 3 stars 2 forks ... joshua eichorn jeichorn@phpdoc.org gregory beaver cellog@php.net chuck ...Missing: 2002 | Show results with:2002
[18]
PhpDocumentor 1.2.2 Manual | PDF - Scribd
Rating 1.0 (1) Introduction to phpDocumentor. Authors:Joshua Eichorn mailto:jeichorn@phpdoc.org Gregory Beaver mailto:cellog@sourceforge.com Kellin mailto:passionplay ...Missing: origins | Show results with:origins
[19]
[PDF] Advanced Ajax
□ Understanding Ajax by Joshua Eichorn (2006) contains one of the most well-rounded introductions to Ajax out there, explaining and demon- strating the use ...
[20]
File Source for new_phpdoc.php
// Gregory Beaver <cellog@php.net>. //. // phpDocumentor, a program for creating javadoc style documentation from php code. // Copyright (C) 2000-2002 Joshua ...
[21]
Configuring the Zend Studio PHPDocumentor extension for PHP-GTK
Oct 18, 2006 · Generating PHPDocumentor documentation for PHP-GTK files. Zend Studio 5.x comes bundled with PHPDocumentor and some integration work done.Missing: 2000s | Show results with:2000s
[22]
Advanced PHP Resources - SitePoint
Oct 1, 2002 · Allows you to install PEAR packages (over the network) plus bundle your code for installation. Execute http://pear.php.net/go-pear with the PHP ...
[23]
PhpDocumentor - PEAR - PHP Extension and Application Repository
Release date: 2003-06-05 00:25 UTC Release state: stable. Release uploaded by: cellog. Changelog: The first stable release through PEAR of phpDocumentor
[24]
fig-standards/proposed/phpdoc.md at master · php-fig/fig-standards
**Summary of PSR-5 from https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc.md:**
[25]
Releases · phpDocumentor/phpDocumentor - GitHub
Jul 21, 2025 · phpDocumentor is now executable on php 8.3 and 8.4 This does not mean we have support for all language additions yet. As we told in the previous ...Missing: PEAR | Show results with:PEAR
[26]
Coding Standards (Symfony Docs)
When PHPDoc tags like @param or @return include null and other types, always place null at the end of the list of types. Naming Conventions. Use camelCase ...
[27]
Basic Syntax - phpDocumentor
This chapter gives an overview of the syntax of "DocBlocks". The precise effect of a tag including examples are provided in different chapters which are ...
[28]
phpDocumentor
### Summary of @todo Tag Usage
[29]
Deprecated - phpDocumentor
The `@deprecated` tag indicates elements to be removed in a future version because they are obsolete or not recommended, and are listed in the deprecated ...
[30]
phpDocumentor
**Summary of {@link} Inline Tag (from https://docs.phpdoc.org/guide/references/phpdoc/inline-tags/link.html):**
[31]
phpDocumentor
- **Syntax**: `{@inheritdoc}`
[32]
phpDocumentor
### Summary of {@internal} Inline Tag
[33]
phpDocumentor Inline tags
Inline tags display in the text flow where they appear. As of version 1.2, there are several inline tags. The allowed inline tag list is different for ...
[34]
phpDocumentor
- **Description**: The `@author` tag documents the author of Structural Elements, indicating the creator or significant modifier. It may include an email address in angle brackets, adhering to RFC 5322 or RFC 2822 (section 3.4.1).
[35]
phpDocumentor
### Summary of `@version` Tag in PHPDoc
[36]
phpDocumentor
**Summary of @copyright Tag in PHPDoc (from https://docs.phpdoc.org/guide/references/phpdoc/tags/copyright.html):**
[37]
https://docs.phpdoc.org/guide/references/phpdoc/tags/var.html
[38]
package - phpDocumentor
@package. The @package tag is used to categorize Structural Elements into logical subdivisions. Syntax. @package [level 1]\\[level 2]\\[etc.] Description.
[39]
category - phpDocumentor
Inheritance ... The @category tag was meant in the original de-facto Standard to group several Structural Elements by their @package tags into one category.<|control11|><|separator|>
[40]
Internals - phpDocumentor
Static analysis tools MAY indicate the use of internal elements from another library/package with a warning or notice. An additional use of @internal is to ...
[41]
param - phpDocumentor
The `@param` tag documents a single function/method argument, its type, and intent. It's recommended for arguments without type info, and only one per argument.
[42]
Definition of a 'Type' - phpDocumentor
A keyword defining the purpose of this type. Not every element is determined by a class but still worth of a classification to assist the developer in ...Missing: standard | Show results with:standard<|control11|><|separator|>
[43]
var - phpDocumentor
You may use the @var tag to document the Type of the following Structural Elements : Constants, both class and global scope; Properties; Variables, both global ...<|control11|><|separator|>
[44]
return - phpDocumentor
With the @return tag it is possible to document the return Type of a function or method. When provided it MUST contain a Type to indicate what is returned; the ...
[45]
PHPStan 1.6.0 With Conditional Return Types and More!
Apr 26, 2022 · Conditional return types allow you to write an “if-else” logic in the PHPDoc @return tag. /** * @return ($as_float is true ?
[46]
throws - phpDocumentor
The `@throws` tag indicates if a structural element throws a specific Throwable (exception or error), and the type must implement the Throwable interface.
[47]
method - phpDocumentor
The @method tag is used in situations where a class contains the \__call() or \__callStatic() magic method and defines some definite uses.
[48]
property, @property-read, @property-write - phpDocumentor
The @property-read and @property-write variants MAY be used to indicate "magic" properties that can only be read or written. For example, the @property-read tag ...Missing: Laravel | Show results with:Laravel
[49]
global - phpDocumentor
The function/method @global syntax MAY be used to document usage of global variables in a function, and MUST NOT have a $ starting the third word.
[50]
Inheritance - phpDocumentor
The inline tag {@inheritDoc} is used in a description to import the description of a parent element, even if the child element already has a description.
[51]
Traits - Manual - PHP
Traits are a mechanism for code reuse in single inheritance languages such as PHP. A Trait is intended to reduce some limitations of single inheritance.
[52]
Properties - Manual - PHP
As of PHP 8.1.0, a property can be declared with the readonly modifier, which prevents modification of the property after initialization. Prior to PHP 8.4.0 a ...
[53]
PHPDocs Basics | PHPStan
PHPDocs are a big part of what makes PHPStan work. PHP in its most recent versions can express a lot of things in the native typehints.
[54]
phpdocumentor/phpdocumentor - Packagist
dev-release-2.0.1. This package is auto-updated. Last update: 2025-11-10 02 ... Inspired by its predecessors, phpDocumentor 1 and JavaDoc, phpDocumentor ...
[55]
Templates - phpDocumentor
A specialized writer which uses the Twig templating engine to convert templates to HTML output. Search results
[56]
phpDocumentor
### Summary of phpDocumentor Configuration Options
[57]
ApiGen/ApiGen: PHP 7.1 ready Smart and Simple Documentation ...
Smart and Readable Documentation for PHP projects. ApiGen is easy to use and modern API doc generator supporting all PHP 8.3 features.
[58]
[READ-ONLY] task-phpdoc - GitHub
This task runs phpDocumentor, a API documentation tool. This project is the result of the merge of the phpDocumentor and DocBlox projects.<|separator|>
[59]
The PropertyInfo Component (Symfony Docs)
This extractor depends on the symfony/doctrine-bridge and doctrine/orm libraries. Using entity mapping data from Doctrine ORM, the DoctrineExtractor provides ...
[60]
Extensions - phpDocumentor
PhpDocumentor can be extended with additional functionality by installing extensions. By default the application will search for an extensions` folder in the .Missing: Laravel tags
[61]
Generating documentation - phpDocumentor
Generating documentation. After you have installed phpDocumentor you can use the phpdoc command to generate your documentation.
[62]
hangs on huge codebase · Issue #1320 · phpDocumentor ... - GitHub
Jun 18, 2014 · I was running some 2.0.0-alpha so i upgraded yesterday to 2.5.x it seems. Now my jenkins jobs hang when they simultaniously try to start phpdoc.
[63]
PHPDoc comments | PhpStorm Documentation - JetBrains
Jun 17, 2024 · PhpStorm allows you to render PHPDoc comments in the editor. Rendered comments are easier to read, and they do not overload your code with extra ...
[64]
Reference of all supported phpdoc tags
Jul 17, 2021 · PhpStorm supports all tags described in the PHPDoc official documentation. Besides, some tags from other tools are supported, too. For ...Missing: general- purpose
[65]
PHP type checking | PhpStorm Documentation - JetBrains
Feb 25, 2025 · If you enforce the type safety of your PHP code with PHPDoc type annotations or the attribute syntax, PhpStorm will infer the defined types of ...
[66]
PHPDocs - Documentation - Zend
PHPDocs provides structured, easy-to-read documentation of all your php elements. PhpDocumentor can automatically create PHPDocs from your scripts.
[67]
Zend Studio 5 - Featured PHP IDE
PHPDocumentor Support. Syntax highlighting for PHPDoc comments; Code Completion for PHPDoc tags and variables in PHPDoc comments; Enhanced and detailed PHPDoc ...
[68]
PHP Intelephense - Visual Studio Marketplace
Advanced PHPDoc type system supporting templates and callable signatures. Reads PHPStorm metadata for improved type analysis and suggestions.
[69]
Top 10 VS Code Extensions for PHP Developers in 2024
Jul 1, 2024 · 6. PHP DocBlocker ... Description: PHP DocBlocker simplifies the process of writing PHPDoc comments. It can automatically generate doc blocks for ...
[70]
Vim for PHP: The Complete Guide for a Powerful PHP IDE
Sep 6, 2017 · The list of plugins I propose here will cover most of your needs: project management, autocompletion, PHPDoc generation, powerful search and replace tools, ...Php Vim Plugins · Generating Ctags · 1 - Universal Ctags<|separator|>
[71]
SublimeText/PhpDoc: PhpDoc support package. - GitHub
CodeDoc is a Sublime Text 2/3 plugin to speedup writing documenting comments. Currently, PhpDoc for PHP is supported, therefore CodeDoc is renamed to PhpDoc.
[72]
PHP Standards Recommendations - PHP-FIG
Each PSR has a status as it is being worked on. Once a proposal has passed the Entrance Vote it will be listed here as "Draft".PSR-2: Coding Style Guide · PSR-1: Basic Coding Standard · PSR-4: Autoloader
[73]
The State of PHP 2025 – Expert review - The JetBrains Blog
Oct 15, 2025 · The 2025 results confirm that PHP remains a stable, professional, and evolving ecosystem. ... Starting July 30, 2025, we're making Laravel Idea ...