About perl bug pattern checking program

Discussion in 'Perl Misc' started by leohan, Apr 7, 2006.

  1. leohan

    leohan Guest

    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, Apr 7, 2006
    #1
    1. Advertising

  2. 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::pluggable 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, Apr 7, 2006
    #2
    1. Advertising

  3. leohan

    leohan Guest

    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::pluggable rather than
    > creating an entirely new module?


    I didn't heard about B::Lint::pluggable 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, Apr 7, 2006
    #3
  4. "leohan" <> wrote in
    news::

    > 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/clpmisc_guidelines.html
     
    A. Sinan Unur, Apr 7, 2006
    #4
  5. 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::pluggable rather than
    >> creating an entirely new module?

    >
    > I didn't heard about B::Lint::pluggable 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
     
    Tad McClellan, Apr 7, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. brad
    Replies:
    2
    Views:
    3,968
    Joe Smith
    Jan 19, 2004
  2. Replies:
    17
    Views:
    1,892
    Chris Uppal
    Nov 16, 2005
  3. Replies:
    1
    Views:
    234
    Gabriel Genellina
    Aug 21, 2007
  4. Clint Olsen
    Replies:
    5
    Views:
    155
    Clint Olsen
    Feb 9, 2004
  5. Replies:
    10
    Views:
    206
    Anno Siegel
    Feb 9, 2006
Loading...

Share This Page