Re: "php -l" - does it find *anything*?

On Tue, Jul 6, 2010 at 8:22 AM, Gary . <php-general@garydjones.name> wrote: > Ashley Sheridan writes: >> On Tue, 2010-07-06 at 10:54 +0200, Gary . wrote: > >>     If foo3 never happens to be called when I am doing my testing (for >>     example if the call is in some "if" branch that is never exercised) then >>     it only gets found in production, so I would like to find this kind of >>     thing using a static analyser. The kind of problem in foo2 I could live >>     with, but would like to find as well, if possible. (Obviously I am using >>     these two example problems as indicative of the type of things I want to >>     find, it isn't an exhaustive list!) >> >>     BTW, what problems *does* "php -l" pick up? I can't find a description >>     anywhere. >> >> According to the man page for php, the -l flag only checks the syntax, so a >> warning wouldn't be displayed, as technically it's not a show-stopper. > > Well, I think foo3 is, but yeah, I know what you mean. > >> Maybe >> some sort of unit testing would help pick out these sorts of issues? > > I do. Actually I posted this by mistake to the phpunit mailing list > first :) > >> As PHP >> isn't a compiled language, I guess it's harder for it to pick up on things >> like this. > > Yeah. There are static checkers out there, even some FOSS ones. I guess > I'm just a bit frustrated that (as you say) the man page says that "-l" > checks syntax but doesn't really detail what kind of things that > covers. Actually, I can't even find a decent description of what > E_STRICT covers :( just that "Enabling E_STRICT during development has > some benefits. Just to interject a little newbie talk... have you ever written a program alone(something developers do for specific situations a lot I find), and not properly written out the documentation because YOU understood what you were doing, but were more into the code than docking it?. This does seem to be a predominant theme amongst some open source projects. STRICT messages will help you to use the latest and > greatest suggested method of coding, for example warn you about using > deprecated functions." > > "Some benefits"? "For example"? Telling people exactly what is covered > seems more useful, to me. Meh. Anyway, that's my whine over for the day > :) > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >