About perl bug pattern checking program

[leohan]

Dear members:
I don't know if I can post my idea in this group.
If I'm wrong please forgive me...
------

Perl is a free style programming language, which has no standard style
to obey, so most
of the users can freely write their code in their own opinion. But the
strict and warning flag
has many limitation on it.

I'm interested in building perl programs' bug pattern checking, and
some of you may be heard
about Lint.pm perl module, which is kind of warning module. And I added
some more useful
extention patterns to this module.

Here's a pdf slide file, which listed bug patterns.

http://ropas.snu.ac.kr/~leohan/lintex/ropastalk.pdf

your any question or argument is welcome...

or if you have some other latency bug patterns can be added to here,
you can comment me...

I'll post my lintex.pm module in a short day.

Thanks very much...

 

[Tad McClellan]

Perl is a free style programming language, which has no standard style
to obey,

I'm interested in building perl programs' bug pattern checking, and
some of you may be heard
about Lint.pm perl module, which is kind of warning module.

I cannot find that module on CPAN.

Did you instead mean the B::Lint module?

And I added
some more useful
extention patterns to this module.

Have you looked into using B::Lint:luggable rather than
creating an entirely new module?

Here's a pdf slide file, which listed bug patterns.

Why not just post the POD for your module?

your any question or argument is welcome...

I would have many more comments to make if I didn't have to copy/paste
stuff from Acrobat to provide context.

If you posted your POD, the context would be right there for all to see.

You use "Errors" in your title when precious few of the warnings
it produces actually are errors.

It is not an "error" to use a poor programming style, it is
merely a "bad idea".

This option warns whenever function identifiers, filehandle names
or hash variable names conflicting with Perl's internal reserved words.

Why doesn't it also warn whenever a scalar or array variable name
conflicts with Perl's internal "reserved words"?

Shouldn't is also warn when a format name or label conflicts?

open STDOUT, "foo.pl";

1) That is (intended to be) the standard idiom for redirecting STDOUT.

You are saying that it is an "error" or "bug" to redirect STDOUT?

Seems to me like a reasonable (ie. not buggy) thing to want to do...

2) Opening STDOUT only for *input* like that actually _is_ an "error".

Does your module warn when you open STDOUT for input?

3) You should always, yes *always*, check the return value from open().

Does your module warn when you do not test the return value from open?

my %ENV = {"a" => 1, "b" => 2}; #ENV is a reserved word

Surely you meant to have parenthesis there instead of curly braces:

my %ENV = ("a" => 1, "b" => 2);

The ENV in your code there has nothing to do with Perl's special
variable named %ENV. The one in your code is a lexical variable,
the special one is a package variable.

Does your module warn when you have a package variable in the
current package with the same name as a lexical variable that
is in scope?

If so, then the "specialness" of names doesn't matter, it should
warn even when you do:

our $x;
my $x;

This option warns whenever filehandle names are written in lowercase

Why doesn't it warn when dirhandle or label names are written in lowercase?

This option warns whenever programmer uses unassigned variables ^^^^^^^^^^
or functions

Does it warn if you had

$k = undef; # this quite clearly _is_ an assignment

at the top of the code?

If you had this at the top:

$foobar = undef;
$k = $foobar;

would you get a warning?

I think you meant "undefined" rather than "unassigned".

or functions

What does an "unassigned function" mean?

Are you referring to lvalue functions or something?

(I think you meant "undefined function"?)

redefine variable

I am pretty sure that you mean "redeclare variable" there instead.

$x = 1;
$x = 99; # redefine $x here

You don't mean that you warn in that situation, do you?

It seems that warning about declaring variables named $a or $b
might be worthwhile. Your code uses those names, but you don't
say anything about warning for using those particular names.

or if you have some other latency bug patterns can be added to here,

Using the dollar-digit variables without first testing to see
if the match succeeded. (your code actually has this bug in it!)

Not testing the return value from open().

Not testing the return value from close() for "pipe opens".

Using double quotes when single quotes would do.

Using variables named $a or $b.

Calling a subroutine using an ampersand.

I'll post my lintex.pm module in a short day.

If you are that close to release, then you surely already have
your POD prepared. Please post that instead of cross-referencing
out to a PDF file.

 

[leohan]

Tad McClellan 작성:

I cannot find that module on CPAN.

It is not yet finished, it now in progress, I'm now considering about
feedbacks...

Did you instead mean the B::Lint module?

I established my module based on the lint.pm module. actually, I added
and
overwritted on it.

Have you looked into using B::Lint:luggable rather than
creating an entirely new module?

I didn't heard about B::Lint:luggable before, so made it without any
idea about
Pluggable module... But mine seems works well...

Why not just post the POD for your module?

I did this presentation in my laboratory this morning, and I had no
time to post it
as POD. Sorry, But if my module and idea is welcomed, than I'll soon
change format.
And I almost finished my module, and I will add and reconfigure module
with your idea.

I would have many more comments to make if I didn't have to copy/paste
stuff from Acrobat to provide context.

I'll be very glad and thanks to you for your any comments, whether
what kind of
comments are... And sorry for you copied from my pdf file to here...

If you posted your POD, the context would be right there for all to see.

I'll soon do that...

You use "Errors" in your title when precious few of the warnings
it produces actually are errors.

then, should I change the "Errors" to "fault"?

It is not an "error" to use a poor programming style, it is
merely a "bad idea".



Why doesn't it also warn whenever a scalar or array variable name
conflicts with Perl's internal "reserved words"?

Ok, I'll add them. That's right.

Shouldn't is also warn when a format name or label conflicts?

I'll add them too, seems useful
I was did this alone in a short time, so I didn't think about these
many things...

1) That is (intended to be) the standard idiom for redirecting STDOUT.

You are saying that it is an "error" or "bug" to redirect STDOUT?

Seems to me like a reasonable (ie. not buggy) thing to want to do...

2) Opening STDOUT only for *input* like that actually _is_ an "error".

Does your module warn when you open STDOUT for input?
no


3) You should always, yes *always*, check the return value from open().

Does your module warn when you do not test the return value from open?

no, but do you mean some thing like following die expression?

open IN, "file" or die "warning: no file";

Surely you meant to have parenthesis there instead of curly braces:

mistake...

my %ENV = ("a" => 1, "b" => 2);

The ENV in your code there has nothing to do with Perl's special
variable named %ENV. The one in your code is a lexical variable,
the special one is a package variable.

but this is confusing users, I think...

Does your module warn when you have a package variable in the
current package with the same name as a lexical variable that
is in scope?

If so, then the "specialness" of names doesn't matter, it should
warn even when you do:

our $x;
my $x;

yes, my module is warn at this case.

Why doesn't it warn when dirhandle or label names are written in lowercase?

I'll add this pattern as soon as possible. seems good idea

Does it warn if you had

$k = undef; # this quite clearly _is_ an assignment

no, my module treat it as an assignment now, but I think I should warn
in this
case, some thing more like:
$k = ""

at the top of the code?

If you had this at the top:

$foobar = undef;
$k = $foobar;

would you get a warning?
no,


I think you meant "undefined" rather than "unassigned".

yes, mine is "unassigned". But change go "undefined" would be better...

What does an "unassigned function" mean?

Are you referring to lvalue functions or something?

(I think you meant "undefined function"?)

my God, that my stupid mistake. I'm not from English speaking country,
so
I made such mistake... Thanks for your kindness to correct this.

I am pretty sure that you mean "redeclare variable" there instead.

$x = 1;
$x = 99; # redefine $x here

You don't mean that you warn in that situation, do you?

mine is warn if $x is assigned a value, but $x is reassigned another
value(99) without using the previous value(1)

It seems that warning about declaring variables named $a or $b
might be worthwhile. Your code uses those names, but you don't
say anything about warning for using those particular names.




Using the dollar-digit variables without first testing to see
if the match succeeded. (your code actually has this bug in it!)

I agree on it

Not testing the return value from open().



Not testing the return value from close() for "pipe opens".



Using double quotes when single quotes would do.

is it worthwhile? what is the problem?

Using variables named $a or $b.

do you mean my module should warn all these simple variable names?
just for readability?

Calling a subroutine using an ampersand.

do you mean using subroutine like following should warn? why?

&foo();
sub foo {
....
}

If you are that close to release, then you surely already have
your POD prepared. Please post that instead of cross-referencing
out to a PDF file.

Thanks very much, really. You helped me a lot.
I did many mistakes in my slide and I will correct them.

But do you really think that these kind of light weight analyzer useful
in perl world?
I need this answer.

For me, this is very useful actually...

thanks again...

sincerely

 

[A. Sinan Unur]

open IN, "file" or die "warning: no file";

Use warn to warn. die'ing is not the only way to check if open succeded.
Also, it is good practice to include reason why the file could not be
opened by including the $! variable in the error message.

Sinan

--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

 

[Tad McClellan]

Tad McClellan ??: ^^^^^^^
^^^^^^^

It is not yet finished, it now in progress,

I thought you said yours was named LintEX, I'm trying to find
the Lint module that you mention, there are a bunch of them:

B::Lint

Test::HTML::Lint

HTML::Lint

MARC::Lint

Apache::Lint


But there *are no* modules named simply "Lint"...



You must have meant the B::Lint module, as you've copied its
docs into your PDF.

I didn't heard about B::Lint:luggable before,

You are developing a module named "Lint" but you didn't search
CPAN to see other modules named "Lint"?

That seems an inefficient development method...

I did this presentation in my laboratory this morning, and I had no
time to post it
as POD.

You should have started with POD. You could probaby get "pod2pdf"
to generate your slides for you from the pod.

then, should I change the "Errors" to "fault"?

I would use "warnings" instead of "errors".

The standard docs (eg. perldiag.pod) for Perl make this same distinction.



You didn't comment on my comment there.

Let me restate my comment:

Your module should not warn about things that are reasonable
in error-free code.

It is reasonable to redirect STDOUT.

Otherwise, folks that want to do this reasonable thing will not
make use of your module.

(Personally, I think this idea is a bit of "The Boy Who Cried Wolf",
I doubt that I would ever use a module that spit out 20 warnings
when my response to 18 of them is "I _meant_ to do that" while
only 2 actually find something worth changing.
)

no

It should. Shouldn't it?

no, but do you mean some thing like following die expression?

open IN, "file" or die "warning: no file";

Yes. Or something like:

unless ( open IN, "file" )
{ do something, maybe call die() }

or

return unless open IN, "file";

Basically, it should warn whenever open() is not in a "boolean context".

yes, my module is warn at this case.

Ack!

So if someone wants to use your module, and have it report nothing,
they must keep track of every variable name in their entire program
to ensure that they don't use a different variable with the same name?

Now I'm to the point that I doubt I would even bother to install
the module, let alone use it.

my God, that my stupid mistake. I'm not from English speaking country,
so
I made such mistake...

No problem.

Thanks for your kindness to correct this.

You're welcome.

I have a good bit of experience decoding English-from-a-Korean-speaker,
because that is how my wife speaks.



I'm not too sure that you understand the profound difference
between "declare" and "define". Please keep at it until you
see how they are very very different.

is it worthwhile? what is the problem?

the hard-to-read:

"C:\\Program Files\\Sell Your Soul"

becomes the less-hard-to-read:

'C:\Program Files\Sell Your Soul'


But the most important reason is that it an opportunity to
indicate your intent:

'the cost is $100'

where $100 is intended to be literal, while

"the cost is $100"

means you better have a pattern with at least 100 set of
parenthesis in your program.

When debugging:

Single quotes mean "no variable here, no need to pay close attention
to the contents of this string".

Double quotes mean "might be a variable in here, better look carefully"


so:

my $str = "this is a pretty long string. it takes a long time to read";

"tricks" the maintenance coder into spending more time on this
line of code than would be needed had the original programmer written:

my $str = 'this is a pretty long string. it takes a long time to read';

do you mean my module should warn all these simple variable names?

No, I mean that it should warn only for those 2 exact names,
because they are "special variables" used by the sort() function.

do you mean using subroutine like following should warn?


Yes.


why?

perldoc -q "&"

What's the difference between calling a function as &foo and foo()?

But do you really think that these kind of light weight analyzer useful
in perl world?

No, in my opinion.