Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This code block has a period after "$one" in the @param:
/**
* Determine blah.
*
* @param string $one.
* One.
* @param string $two
* Two.
*
* @return boolean
* Return.
*/
function uw_ldap_group_exists($one, $two) {}
The error this generates is incorrect:
Doc comment for parameter $one. does not match actual variable name $two
Comments
Comment #2
anoopjohn commentedWhat would be the correct way to address this?
Comment #3
klausiThere is probably a problem wiith the regex that splits up the @param line. I would say the param name should include everything until the next space, then the error messages will be a bit more clear: "Doc comment for parameter $one. does not match actual variable name $one"
We could also check if the variable name ends in a dot and throw an error for that (and skip further processing of that param line).
Comment #4
anoopjohn commentedConsidering the generic case where this fails (not just the period suffix case) the loop to find the real parameter for a given parameter loops through to the end and the checkPos would point to the last real parameter. So the error message would always say that the param does not match the last real parameter.
When the number of parameters documented = number of real parameters for the function then it is possible to say that a specific parameter does not match the corresponding real parameter. When the number does not match then it is not straightforward trying to match the real arguments. This is again doable if the
The case mismatch test also only catches the case mismatch scenario when there is only one argument or when the case mismatch is in the last argument. So this logic also has gaps.
The solution would be to refactor the check for the match with the real parameter outside of the params loop and store the information about the matches for all parameters and then also check for the case mismatch scenario as well as best matching the corresponding real parameter.
Should we really try to say that a specific documented parameter does not match a specific real parameter? Isn't it enough to say that the parameter does not match any of the real parameters listed in the function?
Comment #5
anoopjohn commentedComment #6
klausiWe could also introduce a new error 'Parameter name "$one." contains illegal character(s)" and then simply stop further checking for this parameter.
Comment #8
klausiPushed a change for FunctionCommentSniff to detect trailing dots in param names.