"php -l" - does it find *anything*?
in [General]
|
Prev: Question about the Board
Next: cache_control_limiter
From: "Gary ." on 6 Jul 2010 04:54 Or, alternatively put, is there any way to find the kind of problems in foo2 & foo3 (below), at "*compile* time"? ,----[ lint-test.php ] | <?php | | error_reporting(E_ALL | E_STRICT); | | function foo1() | { | $bar = 'cheese'; | echo $bar; | } | | function foo2() | { | $bar = 'cheese'; | echo 'cheese'; | } | | function foo3() | { | // $bar = 'cheese'; | echo $bar; | } | | foo1(); | foo2(); | foo3(); | | ?> `---- I only get errors displayed when code happens to pass down the code path, i.e. at runtime: ,---- | /home/jg/work $ php -l lint-test.php | No syntax errors detected in lint-test.php | /home/jg/work $ php lint-test.php | cheesecheese | Notice: Undefined variable: bar in | /home/jg/work/lint-test.php on line 20 | | Call Stack: | 1.0000 61488 1. {main}() | /home/jg/work/lint-test.php:0 | 1.0000 61680 2. foo3() | /home/jg/work/lint-test.php:25 `---- 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.
From: Ashley Sheridan on 6 Jul 2010 05:30 On Tue, 2010-07-06 at 10:54 +0200, Gary . wrote: > Or, alternatively put, is there any way to find the kind of problems in > foo2 & foo3 (below), at "*compile* time"? > > ,----[ lint-test.php ] > | <?php > | > | error_reporting(E_ALL | E_STRICT); > | > | function foo1() > | { > | $bar = 'cheese'; > | echo $bar; > | } > | > | function foo2() > | { > | $bar = 'cheese'; > | echo 'cheese'; > | } > | > | function foo3() > | { > | // $bar = 'cheese'; > | echo $bar; > | } > | > | foo1(); > | foo2(); > | foo3(); > | > | ?> > `---- > > I only get errors displayed when code happens to pass down the code > path, i.e. at runtime: > ,---- > | /home/jg/work $ php -l lint-test.php > | No syntax errors detected in lint-test.php > | /home/jg/work $ php lint-test.php > | cheesecheese > | Notice: Undefined variable: bar in > | /home/jg/work/lint-test.php on line 20 > | > | Call Stack: > | 1.0000 61488 1. {main}() > | /home/jg/work/lint-test.php:0 > | 1.0000 61680 2. foo3() > | /home/jg/work/lint-test.php:25 > `---- > > 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. Maybe some sort of unit testing would help pick out these sorts of issues? As PHP isn't a compiled language, I guess it's harder for it to pick up on things like this. You don't need to declare a variable before using it in PHP like you do in a compiled language (without getting into the murky territory of compiled PHP!) so some things might only be picked up by unit testing. Thanks, Ash http://www.ashleysheridan.co.uk
From: Peter Lind on 6 Jul 2010 05:47 On 6 July 2010 11:30, Ashley Sheridan <ash(a)ashleysheridan.co.uk> wrote: > On Tue, 2010-07-06 at 10:54 +0200, Gary . wrote: > >> Or, alternatively put, is there any way to find the kind of problems in >> foo2 & foo3 (below), at "*compile* time"? >> >> ,----[ lint-test.php ] >> | <?php >> | >> | error_reporting(E_ALL | E_STRICT); >> | >> | function foo1() >> | { >> | Â Â $bar = 'cheese'; >> | Â Â echo $bar; >> | } >> | >> | function foo2() >> | { >> | Â Â $bar = 'cheese'; >> | Â Â echo 'cheese'; >> | } >> | >> | function foo3() >> | { >> | // Â Â $bar = 'cheese'; >> | Â Â echo $bar; >> | } >> | >> | foo1(); >> | foo2(); >> | foo3(); >> | >> | ?> >> `---- >> >> I only get errors displayed when code happens to pass down the code >> path, i.e. at runtime: >> ,---- >> | /home/jg/work $ php -l lint-test.php >> | No syntax errors detected in lint-test.php >> | /home/jg/work $ php lint-test.php >> | cheesecheese >> | Notice: Undefined variable: bar in >> | /home/jg/work/lint-test.php on line 20 >> | >> | Call Stack: >> | Â Â 1.0000 Â Â Â 61488 Â 1. {main}() >> | Â Â /home/jg/work/lint-test.php:0 >> | Â Â 1.0000 Â Â Â 61680 Â 2. foo3() >> | Â Â /home/jg/work/lint-test.php:25 >> `---- >> >> 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. Maybe some sort of unit testing would help pick out these > sorts of issues? As PHP isn't a compiled language, I guess it's harder > for it to pick up on things like this. You don't need to declare a > variable before using it in PHP like you do in a compiled language > (without getting into the murky territory of compiled PHP!) so some > things might only be picked up by unit testing. > Yeah, unit testing is definitely the way to go, +1 on that idea. Regards Peter -- <hype> WWW: http://plphp.dk / http://plind.dk LinkedIn: http://www.linkedin.com/in/plind BeWelcome/Couchsurfing: Fake51 Twitter: http://twitter.com/kafe15 </hype>
From: "Gary ." on 6 Jul 2010 08:22 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. 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 :)
From: David Hutto on 6 Jul 2010 08:37
On Tue, Jul 6, 2010 at 8:22 AM, Gary . <php-general(a)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 > > |