in reply to The maybe it is better written this way tool

@files = `ls *.xml|more`;

This example is pretty far fetched. You're asking for a tool to assist *Perl* programmers that understands (correctly or otherwise) that the *shell* command 

ls *.xml | more

[download]
is a bad way of writing 
echo *.xml

[download]

A tool that converts 

chomp( my @files = `echo *.xml` );

[download]
to the better 
my @files = glob('*.xml');

[download]
is already pretty far fetched.

Yet another example would be the extensive processing of values from @ARGV that could be replaced by the use of Getopt::Long.

Seems to me that "processing @ARGV" is hard to quantify into a test.

That said, there does exist a framework for notifying users of bad code. It's Perl::Critic. It doesn't modify the code since the idea is to identify as many possible problems as possible. You'd expect false positives here. Presumably a user willing to use Perl::Critic will look at the documentation to figure out what the warning he gets means. The recommended change can be placed there.

Now I notice you mentioned Perl::Critic. You seem to dismiss it. Why is that? Because no one coded all your suggestions yet? ( Apparently, it already checks for your first example )

Replies are listed 'Best First'.
Re^2: The maybe it is better written this way tool
by szabgab (Priest) on Nov 15, 2009 at 07:13 UTC
    Err, I don't understand what you meant by far fetched? That it will be difficult to pro-grammatically understand the intention? Yes I guess it will. Did you mean something else?
    "processing @ARGV" is hard to quantify into a test.
    That's why I am asking here for suggestions but in what to check and if it seems to be possible. Regarding @ARGV I would look for 2 or more occurrences of either \$ARGV\[ or shift; outside of any sub or shift @ARGV; and then recommend.

    Funny how easily we can misunderstand each other. I mentioned Perl::Critic in my post in order to acknowledge it and to show I am aware of it and not in order dismiss it. Not at all. Though I have not checked Perl::Critic for these I am looking for things that are probably not covered by Perl::Critic (yet?) as they are not really Perl coding styles. If the implementation will be another extension of Perl::Critic or something else is another matter. It would be probably easier for the user (and for the Padre integration) if it was built on top of Perl::Critic.

    As it was pointed out by others at least one of the examples I gave is already covered by Perl::Critic. I should read the book again...

[reply]

      I don't understand what you meant by far fetched?

      Unless you were suggesting the tool should only look for that specific string, the tool would have to know

      • That more's output is being piped.
      • How more behaves when it's output is being piped.
      • The directory from which ls is launched.
      • That the file spec will only match the names of file (not directories).
      • That ls is given a list of file names (not directories).
      • How ls behaves when given a list of file names.

      It would also have to make assumptions such as

      • sh is used as the shell.
      • ls and more aren't aliases.
      • ls and more refer to the standard utilities.

      All this from a program that's suppose to know Perl. And that's just to handle that one command.

      That it will be difficult to pro-grammatically understand the intention? Yes I guess it will

      That it requires an incredible amount of knowledge about non-Perl material to have the slightest clue as to the command's meaning.

      Regarding @ARGV I would look for 2 or more occurrences of either \$ARGV\[ or shift; outside of any sub or shift @ARGV; and then recommend.

      That's no good. Whether you're doing it "correctly" or not, all you have to do with @ARGV is loop over it. The number of times @ARGV is referenced (i.e. how you loop over it) does not indicate how its contents are used at all.

[reply]
[d/l]
[select]
        The tool does not need to recognize all the cases, if we can find a few that might already help. It also does not need to give an exact alternative. It can just point in the general direction of a better solution and let the programmer decide if she wants to take the advice or not.
[reply]

In Section Seekers of Perl Wisdom