Php_codesniffer: IncorrectParamVarName: Problem with short and long types (int / integer)

[alexz707]

Hi!
Version: 3.0.0RC4
Ubuntu - Jenkins

Problem:

I get a Warning: Expected "integer" but found "int" for parameter typ

`/**

• Load video
  *
• @param int $gid Gid.
• @return \stdClass
  */
  private function loadVideo(int $gid): \stdClass`

My phpcs.xml looks like this:
`

<!-- Include the whole PSR-2 standard -->
<rule ref="PSR2"/>

<description>My custom coding standard.</description>
<rule ref="Squiz.Commenting.FunctionComment">
    <exclude name="Squiz.Commenting.FunctionComment.MissingParamComment"/>
    <exclude name="Squiz.Commenting.FunctionComment.SpacingAfterParamType"/>
    <exclude name="Squiz.Commenting.FunctionComment.ThrowsNotCapital"/>
</rule>
<rule ref="Squiz.Commenting.FunctionCommentThrowTag" />
<rule ref="Squiz.Commenting.ClassComment">
    <exclude name="Squiz.Commenting.ClassComment.TagNotAllowed"/>
</rule>
<rule ref="Squiz.Commenting.VariableComment" />

`

Is this a bug or do I need to use another rule?

Thanks!

[gsherwood]

This is what the Squiz standard wants to you to use. I will probably change that in the future, but no other standards have any sort of strict documentation rules, so you can't just switch to another rule for this. You'll either need to code a sniff yourself to check this, see if you can find one someone else has written, or exclude Squiz.Commenting.FunctionComment.IncorrectParamVarName from your standard.

[alexz707]

Thanks for the information.
After some research I found https://github.com/slevomat/coding-standard
I think I will use that one until you change your sniffs.

BTW: there is also the same bug with @return int but it is another sniff rule
Squiz.Commenting.FunctionComment.InvalidReturn

Would be awesome if you can fix these errors (at least for 7.1) in the future ;-)
Regards
alex

[bkdotcom]

Re the actual PHP type-declarations / type-hints

https://www.php.net/manual/en/functions.arguments.php#functions.arguments.type-declaration

Aliases (boolean & integer) are not supported. Instead, they are treated as class or interface names. For example, using boolean as a parameter or return type will require an argument or return value that is an instanceof the class or interface boolean, rather than of type bool:

Also the new PSR-12

Short form of type keywords MUST be used i.e. bool instead of boolean, int instead of integer etc.

Nutshell: code requires int or bool type declaration
Squiz.Commenting.FunctionComment.IncorrectParamVarName and
Squiz.Commenting.FunctionComment.InvalidReturn
is requiring integer or boolean in the PhpDoc

750

[filips123]

Considering that PHP documentation, PSR-12 (accepted) and PSR-5 (draft) all require using short type declarations, are there any plans to also support requiring them in code standards?

Could this be done as property for Squiz.Commenting.FunctionComment, just like you already have ignoreBlankLines for Squiz.WhiteSpace.SuperfluousWhitespace? This would allow users to require usage of short types, long types or both.

This also happens with Squiz.Commenting.FunctionComment.InvalidReturn and maybe also some other rules/sniffs.

Update: Similar issue: #1864

[zephyx]

Can't we just update the file /src/Util/Common.php ?

And add the types 'bool' and 'int' to the variable $allowedTypes ?

It's not normal to be compeled to deactivate Squiz.Commenting.FunctionComment.IncorrectParamVarName in order to be compliant to the php7 standard..:/