From: "Gary ." on
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
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
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
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
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
>
>
 |  Next  |  Last
Pages: 1 2
Prev: Question about the Board
Next: cache_control_limiter