Re: Call for Discussion: PHP_Splint: Evaluate PHP code for potential usage and style problems.

Hi Justin (and all),

Date: Fri, 10 Dec 2004 13:26:59 -0800 From: Justin Patrin <papercrane@gmail.com> To: Bishop Bettini <php@ideacode.com> Cc: pear-dev@lists.php.net Subject: Re: [PEAR-DEV] Call for Discussion: PHP_Splint: Evaluate PHP code for

     potential usage and style problems.

On Fri, 10 Dec 2004 15:47:02 -0500 (EST), Bishop Bettini <php@ideacode.com> wrote:

[snip] [b]Summary[/b] PHP_Splint: Evaluate PHP code for potential usage and style problems. [b]Problem[/b] Packages exist to support PHP developers during testing (eg PHPUnit), but no packages exist to support PHP developers during construction. Other languages enjoy rich sets of compilation warnings (eg via gcc) and third-party tools (eg lint), but PHP provides only limited syntax checking. The absence of any exceptional PHP "lint" tool is a huge exposure for application developers, especially those building enterprise and mission-critical applications. [b]Proposal[/b] To provide a package that augments the built-in PHP lint (available through the php_check_syntax() function or the -l command line argument to PHP/CLI), giving developers a far more detailed review than a straight syntax check. This package's lint support aims to address coding issues at the semantic level more than the syntactic level. [snip]

Sounds very nice, I'm definately interested. I would also suggesting adding: * check for variables used without setting * direct access of array indices without an isset() (this may be too complicated to deal with) * access/setting of un-declared class variables * for PHP4, checking of docblocks for @access and then checking of calls for appropriateness

Great, I'll make sure these get into my documentation. I actually have a list of over 100 usage items to check, and over 4 dozen metrics, but I wanted to start with a reasonable set and plug in from there. My initial choices were based on back-of-the-napkin calculations on which would be "easy" to implement and which would be "easy" to understand.

In checking for superfluous functions/classes/variables, it's quite possible that an eval() or indirection is being used. This should definately be mentioned in the description. In addition, setting of classes/vars(/directories/files?) to not check for this would be useful. I could easily see all of my DataObject_* classes falling into this. I would, of course, want them to be checked for everything else.

Agreed. I left out choosing which checks/metrics to run originally after much debate here, but on reflection, it was left out because of the potential problems it might cause in implementation; that's not a sufficient reason to leave it out of the requirements, though! Design document updated to require these.

I would suggest looking into PHP_Beautifier and possibly including support for it (although this may be more of an application-level thing). It may be a good starting point for the code. (maybe make a PHP_Tokenizer class or some-such to use for both).

I've been pondering connections to both PHP_Beautifier and PHP_Parser, but at this time I haven't approached either development team specifically about any connections. Any thoughts from them while drafting are appreciated. On the second point, the design document talks a little about class separation and table-driven methods. Off the cuff, I'll probably have something like: PHP_Splint: provides preparation (adding snippets, files, etc) to "application" delegates to PHP_CodeWalker provides analysis (table-driven "plugins" of checks and metrics) provides reporting (list of results) PHP_CodeWalker: provides methods to create an indexed, normalized, and cross-referenced compendium of the constructs in the given files It is from PHP_CodeWalker that others might be able derive. On the other hand, PHP_CodeWalker might not actually be a part of this class; PHP_Parser might just be what I use. My concern being that PHP_Parser is also new, and I generally try to avoid dependencies. Regards, bishop -- ideacode, Inc. Genuine Ingenuity. http://www.ideacode.com/