Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.7.2

Bug #13827 AbstractVariableSniff throws "undefined index"
Submitted: 2008-05-02 22:17 UTC
From: blacksheepkhan Assigned: squiz
Status: Closed Package: PHP_CodeSniffer (version 1.1.0a1)
PHP Version: 5.2.5 OS: Windows
Roadmaps: 1.1.0    

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 16 + 10 = ?

 [2008-05-02 22:17 UTC] blacksheepkhan (Thomas Weidner)
Description: ------------ Running a class which extends AbstractVariableSniff leads in throwing a notice within AbstractVariableSniff: Notice: Undefined index: scope_closer in C:\php\PEAR\PHP\CodeSniffer\Standards\AbstractVariableSniff.php on line 121 Call Stack: 0.0007 66000 1. {main}() C:\php\phpcs:0 0.0510 1143056 2. PHP_CodeSniffer_CLI->process() C:\php\phpcs:30 0.0568 1147816 3. PHP_CodeSniffer->process() C:\php\PEAR\PHP\CodeSniffer\CLI.php:334 0.6119 4662232 4. PHP_CodeSniffer->processFiles() C:\php\PEAR\PHP\CodeSniffer.php:276 4.6559 5477224 5. PHP_CodeSniffer->processFile() C:\php\PEAR\PHP\CodeSniffer.php:552 4.6709 5573808 6. PHP_CodeSniffer_File->start() C:\php\PEAR\PHP\CodeSniffer.php:600 4.7768 5782152 7. PHP_CodeSniffer_Standards_AbstractScopeSniff->process() C:\php\PEAR\PHP\CodeSniffer\File.php:378 4.7769 5783096 8. PHP_CodeSniffer_Standards_AbstractVariableSniff->processTokenWithinScope() C:\php\PEAR\PHP\CodeSniffer\Standards\AbstractScopeSniff.php:170


 [2008-05-03 02:48 UTC] squiz (Greg Sherwood)
Can you please post the code you were testing at the time.
 [2008-05-03 08:28 UTC] blacksheepkhan (Thomas Weidner)
Good joke... :-) I was testing ZF which contains about 14.000 files in one step. I will try to cut this down a little bit.
 [2008-05-03 08:45 UTC] blacksheepkhan (Thomas Weidner)
I added one of the files I found out to throw this notice as patch "Bad_File".
 [2008-05-04 23:03 UTC] squiz (Greg Sherwood)
Your sample file has a parse error: PHP Fatal error: Non-abstract method Zend_Build_Command_Create::configure() must contain body in /home/gsherwood/PHP_CodeSniffer/temp.php on line 66 The keyword "abstract" is missing from the definition of those abstract functions. When you add it in, PHP_CodeSniffer no longer throws errors either.
 [2008-05-05 06:27 UTC] blacksheepkhan (Thomas Weidner)
But shouldn't CodeSniffer be aware of such and throw a error instead of a PHP notice ?
 [2008-05-05 06:39 UTC] squiz (Greg Sherwood)
Only parse errors should cause PHP_CodeSniffer to throw PHP notices. I leave them so I know when there is a legitimate problem with PHP_CodeSniffer's parsing. If I see one, something is broken. If I determine that it is just caused by a parse error, at least you were alerted to the fact. If you would like to test for parse errors in your code, you can include the ZendCodeAnalyzerSniff in your standard and set the path to ZCA ( - bottom of page). It will check for parse errors and other general problems in your code.
 [2008-05-05 12:43 UTC] blacksheepkhan (Thomas Weidner)
Here are two problems... The notice does not show WHICH file was the problem. This could be a real headache when working with several 1000 files. And if the person does not have Zend Studio he is not able to run the mentioned CodeAnalyser test.
 [2008-05-05 22:08 UTC] squiz (Greg Sherwood)
When I see a notice, I use the -v command line arg to print each file being checked by PHP_CodeSniffer. This then allows you to see which file was being processed when the NOTICE was thrown. If you are having a problem with parse errors in your code, you could just run "php -l" on your files to have the php-cli check it for you.
 [2008-05-08 03:59 UTC] squiz (Greg Sherwood)
Just a note that PHP_CodeSniffer now throws a warning for this case, indicating to the user that there is a possible parse error.
 [2008-05-08 03:59 UTC] squiz (Greg Sherwood)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on by the end of next Sunday (CET). If this was a problem with the website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.