coding-standards icon indicating copy to clipboard operation
coding-standards copied to clipboard

Support {@inheritdoc}

Open piotr-cz opened this issue 10 years ago • 14 comments

Let's consider allowing the {@inheritdoc} tag.

This really helps when extending classes, you don't have to rewrite whole docblock and keep it up to date with docblock changes in base class.

Important bonus is that one can easily see that the property has a parent.

At this moment php code sniffer complains like:

50 | ERROR | Doc comment for "$form" missing
52 | ERROR | Missing @return tag in function comment

This tag is being widely used in projects like Symfony and Drupal.

Usage

class A
{
    /**
     * Foo method
     *
     * @param   array  $bar  Bar
     *
     * @return  void
     */
    public function foo(array $bar)
    {
    }
}

class B extends A
{
    /**
     * {@inheritDoc}
     */
    public function foo(array $bar)
    {
    }
}

References

piotr-cz avatar Dec 23 '13 13:12 piotr-cz

I wouldn't mind it. I'd also suggest following the PSR proposal and https://github.com/phpDocumentor/fig-standards/issues/37 specifically as a tag without the brackets may be introduced. And FWIW, in some code I'm trying out locally, I started using that tag in place of the "proper" doc block.

While I'm thinking about it, if there are any issues with our sniffer not accepting something in the PSR, as it is defined and ratified, we should adjust our rules to adapt, to include potentially throwing warnings on deprecated tags.

On Monday, December 23, 2013, Piotr wrote:

Let's consider allowing the {@inheritdoc} tag.

This really helps when extending classes, you don't have to rewrite whole docblock and keep it up to date with docblock changes in base class.

Important bonus is that one can easily see that the method has a parent.

At this moment php code sniffer complains like:

50 | ERROR | Doc comment for "$form" missing 52 | ERROR | Missing @return tag in function comment

This tag is being widely used in projects like Symfony and Drupal. Usage

class A{ /** * Foo method * * @param array $bar Bar * * @return void / public function foo(array $bar) { }} class B extends A{ /* * {@inheritdoc} */ public function foo(array $bar) { }}

References

  • javadoc: {@inheritdoc}http://docs.oracle.com/javase/6/docs/technotes/tools/solaris/javadoc.html#@inheritDoc
  • phpDocumentor: {@inheritdoc}http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_tags.inlineinheritdoc.pkg.html

— Reply to this email directly or view it on GitHubhttps://github.com/joomla/coding-standards/issues/50 .

mbabker avatar Dec 23 '13 17:12 mbabker

The PSR isn't yet ratified, it's still in progress.

dongilbert avatar Dec 23 '13 17:12 dongilbert

So I'm actually referring to a @inheritDoc tag, that's not yet part of phpDocumentor.

{@inheritdoc} is used just for descriptions or @param's text values.

piotr-cz avatar Dec 23 '13 18:12 piotr-cz

Got that, just saying keep an eye on it as it works through the system, that's all.

On Mon, Dec 23, 2013 at 11:40 AM, Don Gilbert [email protected]:

The PSR isn't yet ratified, it's still in progress.

— Reply to this email directly or view it on GitHubhttps://github.com/joomla/coding-standards/issues/50#issuecomment-31132581 .

mbabker avatar Dec 23 '13 18:12 mbabker

You, but I didn't :smile: Thanks for that link, I didn't know I've been using this tag wrong way all the time.

piotr-cz avatar Dec 23 '13 20:12 piotr-cz

I personally don't like the inheritdoc tag because when I'm inspecting the code I have to work up the inheritance chain to find the documentation. It's not so bad once you get to know the code but I find it annoying if I'm trying to learn the API, not to mention evaluate a pull request. This is something that frustrates me when I look at other frameworks.

Regards, Andrew Eddie http://learn.theartofjoomla.com - free tutorials and videos on Joomla development

eddieajau avatar Dec 23 '13 20:12 eddieajau

@eddieajau I didn't think of this. You are right, this tag makes it harder to learn the API, but easier when working with something you already know. Does anybody know what is the support in IDEs? If one could see the inherited docblock, I think we could start using it but if not, let's not use it ATM

piotr-cz avatar Dec 30 '13 08:12 piotr-cz

New resources to consider:

piotr-cz avatar Apr 03 '15 10:04 piotr-cz

For my experience, PHPStorm cannot show any information of {@inheritDoc}, I have to trace the parent to see docblock.

I'm agree with @eddieajau, I also don't like this tag. It's my personal opinion.

But I think we can wait for PSR-5

asika32764 avatar Apr 04 '15 01:04 asika32764

After CodeSniffer/Standards/PEAR/Sniffs/Commenting/FunctionCommentSniff.php:129 We may put:

        foreach ($tokens[$commentStart]['comment_tags'] as $tag) {
            if (strtolower($tokens[$tag]['content']) == '@inheritdoc') {
                $isSpecialMethod = true;
            }
            [...]
        }

It will work. Perhaps this validation is needed to be replaced with customized one.

andkirby avatar Dec 02 '15 15:12 andkirby

Any progress on this ?

RusAlex avatar May 19 '16 06:05 RusAlex

For example Eclipse does support it and I guess PHPStorm does as well. It makes no sense to copy doc blocks from the base class. If that doc block changes all the subclasses do need to be updated.

laoneo avatar Jun 19 '16 14:06 laoneo

I also don't like it personally and would go with @eddieajau on this.

On the other hand I believe that the sniffer should "allow" it so extension devs may use it as they wish. The code proposed by @andkirby looks good. Maybe a PR would be accepted?

elkuku avatar Jun 19 '16 15:06 elkuku

Apparently this tag is being supported in PHPStorm since v6 (I can't confirm as I'm not using it).

Joomla is the only framework I've used that doesn't implement it.

piotr-cz avatar Jun 19 '16 21:06 piotr-cz