Warnings (yellow) in sub-directories include files...
I have a fairly large project I'm working on...within the top level demon source, there's a directive to load a single file (common.inc) that boot-straps my class autoloader and third-party libs, sets-up my constants and functions files, etc.
Working within the top-level demon .php file, all is green and I have a happy...however, to make the source manageable, I decided to modularize sections of code specific to processing functionality into a sub-directory and just load these modules at run time with a simple require() function call: (require('subdir/module1.php'));
/[common]
/[classes]
/[lib]
/[somedir]
.../demon.php
.../common.inc
.../[subdir]
....../module1.php
....../module2.php
....../ ... etc ...
Functionally, everything still works, but my OCD is getting nose-flicked because the module files went yellow with warnings on classes that are defined and instantiated in the parent (demon.php) file.
I can use @var comments for a few of my class variables in the headers and that knocks out some of the warnings within the module source...but I'm having problems doing the same with the 3P library class variables... so I was thinking there has to be an easier way to do this...
Is there a simple(r) way to mark the module file as a child-file to it's parent so that the parser can resolve unknowns to that level and eliminate the banana-fest I'm seeing along the right-side of my screen within the module files?
Thanks!
--mike
Please sign in to leave a comment.
Hi Michael,
It is very difficult to suggest something concrete without seeing what is actually going on. You description is very colourful and fantastic overall... but still pretty useless for specific advices (at very least some screenshots would help quite a bit. If you can provide some test project that reproduces the situation -- that would be much much better).
Based on the above I may only suggest to play around with additional settings for some of the inspections. e.g.:
I've tried to replicate using a simple example but, if I were successful in doing that, I suspect I would be able to solve this issue...
I've tried selecting 'invalidate cache and restart..." option but no luck.
I've also noticed that when the code first loads, the indicator is solid green (as it is when the code is embedded inline in the parent source) but it flips over to yellow once processed by the IDE...
Anyway, here's a screen shot of the IDE of the parent program showing that the container classes are "green" as is the invocation of the code stub module.
The second screenie shows the IDE for the module -- and the same objects are now yellow-flagged.
I can override with @noinspection but I really don't want to burden the code's readability or maintainability...
Thanks, Andriy!
Attachment(s):
Screenshot from 2012-10-01 13:46:57.png
Screenshot from 2012-10-01 13:46:25.png
Hi there,
As I've expected you are using global variables (at very least -- it is defined in main file but used in included one). The only solution here is to try to tweak "Settings | Inspections | PHP | Undefined | Undefined variable" inspection -- it has option(s) that may help.
And Yes -- you should not really use the @noinspection to surpress warnings -- if possible try reorganizing/refactoring your code (which is not always possible, especially when codebase is big and old).
For example -- try extracting some object in separate variable, assign correct type via inline @var PHPDoc comment and use it -- the need for @noinspection may disappear. As I understand from screenshot, the basic_publish and basic_reject methods are not recognized because they are invoked trough the array index. Maybe adding proper PHPDoc for that array will do the job, otherwise you may want to consider introducing intermediate variable if it will be used more than once, e.g.
As a general advice -- try not to use global variables/objects -- any IDE will fail to a some degree here (the one that actually analyses the code and not just syntax highlighting). You may want to look into working with objects in centralised way (so that you can reach it from any place in your app, via something like myApp::getErrorObject()->...) or maybe Dependency Injection pattern (where you can pass your $errorObject as a parameter to a class method/function, for example).