Re: 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: > Greetings All, > > I am preparing a new proposal for PEAR, and I wanted to start a > discussion thread here before beginning the formal process. The > highlights of the draft proposal are below: > > --- start --- > [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. > > The package name is a backroynm and is recursive: > Splint = "[u]S[/u]plint: [u]P[/u]HP [u]lint[/u]" > > The package name also refers to a "splint," which provides support and > protection for a wounded part. > --- end --- > > If you are interested, I encourage you to please review the following > materials for a more complete picture of the proposal: > > ª§Gm€-åÎMmœ± > ÍLhttp://bishop.ideacode.com/~bishop/work/PHP_Splint/docs/PEPr_Proposal.txt > > http://bishop.ideacode.com/~bishop/work/PHP_Splint/docs/design.html > > http://bishop.ideacode.com/~bishop/work/PHP_Splint/PHP_Splint.php > > Also, bear in mind this package is still in the early development stage, > so all ideas, comments, and questions are very welcome. > 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 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. 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). -- Justin Patrin