«

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...

leohan <> wrote:

> 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.


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas

Tad McClellan 작성:

> leohan <> wrote:
>
> > 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.

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.

>
>
> > 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?

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

>
> > Here's a pdf slide file, which listed bug patterns.
>
>
> 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.

>
> > 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.

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".
>
> > 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"?

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...

>
>
> > 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?

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";

>
>
> > my %ENV = {"a" => 1, "b" => 2}; #ENV is a reserved word
>
> 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.

>
>
> > This option warns whenever filehandle names are written in lowercase
>
>
> 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

>
>
> > This option warns whenever programmer uses unassigned variables
> ^^^^^^^^^^
> > or functions
>
> 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...

>
>
> > or functions
>
> 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.

>
>
> > 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?

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.
>
>
> > 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!)

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 {
....
}

>
>
> > 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.
>
>
> --
> Tad McClellan SGML consulting
> Perl programming
> Fort Worth, Texas

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

"leohan" <> wrote in
news: ups.com:

> 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 <>
(remove .invalid and reverse each component for email address)

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

leohan <> wrote:
> Tad McClellan ??:
>> leohan <> wrote:

>> > about Lint.pm perl module, which is kind of warning module.
^^^^^^^
^^^^^^^
>> I cannot find that module on CPAN.
>
> 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"...


>> Did you instead mean the B::Lint module?


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


>> Have you looked into using B::Lint:luggable rather than
>> creating an entirely new module?
>
> 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...


>> > Here's a pdf slide file, which listed bug patterns.
>>
>> 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.


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


>> 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"?


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

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


>> > 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...


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.
)


>> 2) Opening STDOUT only for *input* like that actually _is_ an "error".
>>
>> Does your module warn when you open STDOUT for input?
>
> no


It should. Shouldn't it?


>> 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";


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".


>> 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?

>> our $x;
>> my $x;
>
> 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.


>> What does an "unassigned function" mean?

>> (I think you meant "undefined function"?)
>
> 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.


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


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.


>> Using double quotes when single quotes would do.
>
> 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';


>> Using variables named $a or $b.
>
> 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.


>> Calling a subroutine using an ampersand.
>
> do you mean using subroutine like following should warn?

> &foo();


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.


--
Tad McClellan SGML consulting
Perl programming
Fort Worth, Texas