You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that in the docblocks we are unsing FQCN when adding types to the parameters. We are also importing those at the top of the file.
In most of the editors, the editor is smart enough that it will know to what class/interface we are referring to.
So we should consider maybe shortening the FQCNs in the docblocks?
Example:
<?php...namespaceWordPressCS\WordPress\Helpers;
usePHP_CodeSniffer\Files\File;
...// Later in the class/trait/interface:
/**
* ...
* @param \PHP_CodeSniffer\Files\File$phpcsFile The file being scanned.
Could be written as:
<?php...namespaceWordPressCS\WordPress\Helpers;
usePHP_CodeSniffer\Files\File;
...// Later in the class/trait/interface:
/**
* ...
* @param File $phpcsFile The file being scanned.
As the File is imported at the top of the file.
Thoughts?
The text was updated successfully, but these errors were encountered:
I tend to favour FQNs in docblocks for two reasons:
Docblocks are not subject to use statements, so while most IDEs are smart enough by now, not everyone uses an IDE and we cannot expect them to.
Docblocks may be re-used outside the context of the code - think a documentation website generated with phpDocumentor or other tooling. In that case, it can be hit-or-miss whether the names will be resolved correctly.
Using FQNs in docblocks prevents issues in both cases.
I noticed that in the docblocks we are unsing FQCN when adding types to the parameters. We are also importing those at the top of the file.
In most of the editors, the editor is smart enough that it will know to what class/interface we are referring to.
So we should consider maybe shortening the FQCNs in the docblocks?
Example:
Could be written as:
As the
File
is imported at the top of the file.Thoughts?
The text was updated successfully, but these errors were encountered: