Inspection "Missing parameter's type declaration" not working.
Today we are integrating the "Inspecions" seriously in our PHP project.
Until today we just used it as suggestions but from today on we'd expect to only commit "if inspections are green light".
Steps:
# Step 1, language level
In a project with language level 7.0 we expect ALL function calls to have the paremeters type-hinted, both class hints and scalar-type hints.
# Step 2, check inspections are active
I have the inspection "Missing parameter's type declaration" activated (it's activated by default, indeed) with "weak warning", although I have also tried as "warning" and the same results, as well as the return type hinting among many others:
# Step 3, place a trap in the code
In my code, I voluntarily comment out the type hint of a parameter and of the return type for a given function, to see if the inspections catch them:
# Step 4, run the inspections
I run the inspections for the full folder with the menu `Code | Inspect code` and I successfully get the inspections window result... but surprisingly it catches the "missing return type" but does not catch the "missing parameter's hint":
Question:
How can I set the configuration up so it catches the `$processId` not being qualified?
Thanks!
PhpStorm Version:
PhpStorm 2021.1 EAP Build #PS-211.4961.37, built on January 28, 2021 PhpStorm EAP User Expiration date: February 27, 2021 Runtime version: 11.0.9.1+11-b1257.1 amd64 VM: Dynamic Code Evolution 64-Bit Server VM by JetBrains s.r.o. Windows 10 10.0 GC: G1 Young Generation, G1 Old Generation Memory: 750M Cores: 12 Registry: run.processes.with.pty=TRUE
Please sign in to leave a comment.
It seems that at the moment you just can't - the type has to be known (from the @param annotation, for instance) for the inspection to fire.
Please submit this as a bug if you think we should change the behavior: https://youtrack.jetbrains.com/newIssue?project=WI
thanks Eugene. Opened issue here: https://youtrack.jetbrains.com/issue/WI-58388
That inspection is not working for me even declared in the DOC block.
ExTexan, it seems that it does - the parameters are marked with inspection warnings. What do you see when you hover the mouse pointer over a parameter on the second screenshot?
Eugene Morozov,
Sorry for the misleading wording. What I meant by "not working" is that it seems to be getting false positives - that is, it's not "seeing" the "@param" annotations.
This is what I see when I hover over the parameters:
This is just one example of many that I'm seeing in my code. Since Drupal seems determined to deprecate a few dozen functions/classes every month or two, I've been trying to use the code analysis to keep my code up-to-date. But when so many "non-errors" show up in the results list, it makes it time-consuming to process the list on a regular basis.
And it's not supposed to. This inspection is specifically about the PHP parameter type declarations; it checks if they are present and advises to add them if they are not. A
@paramannotation is complimentary; it doesn't replace a proper type hint.So, if you don't need this inspection and it's okay to have just
@paramannotations, you can always disable the inspection.Ok, I guess I got confused by what you wrote earlier in the thread:
Doesn't that contradict what you wrote in your latest comment above?
It doesn't. What I meant in this comment is that a
@paramannotation is necessary for this inspection to kick in, because otherwise PhpStorm won't know the parameter type and thus will not be able to provide a quick-fix.I still think this inspection should kick-in without the `@param` annotation being necessary. I don't need the inspector to tell me "hey you should type MyNiceClass here". I'm happy that it tells me "hey you should type something here".
This is why I opened this still-open-issue https://youtrack.jetbrains.com/issue/WI-58388 a year and a half ago, an why I stated this specific comment: https://youtrack.jetbrains.com/issue/WI-58388/Inspection-Missing-parameters-type-declaration-not-working-without-the-PHPDoc-block#focus=Comments-27-4704271.0-0
UserStory made simple:
Ah, I understand now. And I must say, that is neither apparent, nor intuitive, based simply on reading the inspection error message.
So the feature design is like this... The missing type inspection will only fire if we (the devs) have told it, by way of the @param annotation, what *we* think the type should be, just so PhpStorm can have an option in the contextual menu to automatically fix it?
That's not all that useful, is it? I have to agree with Xavi... I don't need an error message *only* if I've provided half the information - I need it whenever something is missing, contextual menu fix option notwithstanding.
I agree with ExTexan in the sense that it's not too much useful. If I already provided a @param it means I already took care of "thinking about that parameter".
Additionally with the newer more-typed PHPs, the dock-blocks are less useful, even redundant. I don't want to have a parameter hinting in the code, a return value in the code, and then having a comment that tells the exact same thing that already is in the code. This would yield in potential missmatches. The greatness of newer PHP versions where we can type parameters, return values (even `void`), we can type properties and even as we can see here https://wiki.php.net/rfc/typed_class_constants targetting PHP 8.2 typing constants, the dockblocks should be completely removable and the code be perfectly both machine- and human-readable.
I still advocate to get a help in making "clean code" with help of the IDE without relying in the @annotations at all. Just get help in pure clean code.