Re^2: The maybe it is better written this way tool

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

Comment on Re^2: The maybe it is better written this way tool

Replies are listed 'Best First'.
Re^3: The maybe it is better written this way tool by ikegami (Patriarch) on Nov 23, 2009 at 19:42 UTC
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]
Re^4: The maybe it is better written this way tool by szabgab (Priest) on Dec 02, 2009 at 20:20 UTC
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]
Re^5: The maybe it is better written this way tool by ikegami (Patriarch) on Dec 02, 2009 at 23:19 UTC
The tool does not need to recognize all the cases You seem to have misunderstood me. All that knowledge and all those assumptions is needed for that one case.	[reply]