-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False positive for undefined variable in wp_parse_str and wp_parse_args #67
Comments
🤔 That's an interesting situation. There's a few aspects of the code you have above and I'm not 100% certain I understand which one or ones you are pointing to, so I'll do my best to answer, but I apologize in advance if I'm misunderstanding! Please correct me if so! Even if some functions, like In the example above, the statement I think that's what you were referring to, but just in case: There's another behavior of |
Yeah, correct. Also, thanks for wording the issue clearly.
I personally see a difference in between the two examples. While in the In the original example, tho, the
I can totally see your point and am happy to disable the sniff for such patterns. Disabling the sniff, is from my point of view, a better solution than alternative, rather verbose, notation:
|
// Recommended
parse_str($str, $output);
echo $output['first']; // value Thanks for linking to that, and for the explanation. I'm starting to think this is sort of like using if ( $_POST['amount'] == 5 ) {
// ...
} So while the WordPress coding standard warns us about the above code, if the developer knows what they're doing, it is probably more clear than In the case of this sniff, The first thing that comes to mind is a whitelist of functions which can be passed undefined variables without a warning. Apparently this sniff already includes such a feature, as part of the original code that I forked! I would just need to add an option to also include the WordPress functions which follow that pattern. I'll see what I can do. |
An example from WordPress phpunit tests producing false-positive reports of undefined variables for both functional lines:
While in the first case, the
$ss
is not being defined at the point ofwp_parse_str
call, it's being created and populated inside the function, in the second case, the$ss
has already been populated.Should be easy to fix the lint issues by defining
$ss
as an empty array prior this code, but the notation in the example feels like a commonly used idiom in PHP (not only forwp_parse_args
, but also forparse_str
and other functions with similar variable creation capability).The text was updated successfully, but these errors were encountered: