Re: Script Critique

Always use strictures (use strict; use warnings; - see The strictures, according to Seuss).

Don't mix subs and main line code. Perl lets you, but it makes it vary hard to see the flow of the main line code.

Where does @results get set? Nothing in the main line code indicates that. Setting global variables as a side effect of calling code is bad!

Will all elements of @results be numeric? If not then your lack of strictures has set you up for nasty results. The spaceship operator <=> numifies its augments and most strings become 0. If you want a string compare use cmp.

Perl is environmentally friendly - it saves trees

Comment on Re: Script Critique

Replies are listed 'Best First'.
Re^2: Script Critique by ikegami (Patriarch) on Jul 21, 2008 at 02:02 UTC
Where does @results get set? Nothing in the main line code indicates that. Setting global variables as a side effect of calling code is bad! He doesn't control File::Find's interface. He has to use a global unless he wishes to mix his input, processing and output into the `find` callback, something I wouldn't do. However, inlining the function makes things appear more local. `my @results; find( sub { ... push @results, ...; }, $dir );` [download] Update: That's one of the reasons I prefer File::Find::Rule.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: Script Critique
by ikegami (Patriarch) on Jul 21, 2008 at 02:02 UTC

Where does @results get set? Nothing in the main line code indicates that. Setting global variables as a side effect of calling code is bad!

He doesn't control File::Find's interface. He has to use a global unless he wishes to mix his input, processing and output into the find callback, something I wouldn't do. However, inlining the function makes things appear more local.

my @results;

find(
   sub {
      ...
      push @results, ...;
   },
   $dir
);
[download]

Update: That's one of the reasons I prefer File::Find::Rule.

[reply]
[d/l]
[select]