First one quick note:

my $file = "file"; # why not...
my $temp = "temp"; # makes sense if you later want to use
                   # some other basename for your sequence of files

foreach (1..5){
  open $file, '>', "$temp$_"; # you just turned $file from a string in
+to a filehandle...
  ...
}
[download]

In other words your assignment in the first line does nothing since the value gets clobbered when you use open

On to your question. I quickly glanced at the node and the author is basically saying that sometimes it is unclear what $_ is supposed to represent. Whether or not this is the case depends on the context that you use it in. For instance:

foreach (@lines) {
  $_ = uc; # ALL CAPS WOOOOOO
  s/$/!!!/; # EVERY LINE IS AN EXCLAMATION!!!
  print;
}
[download]

my @timesTable;
foreach my $row (0..12) { #
  foreach my $col (0..12) {
    @timesTable[$row][$col] = $row * $col;
  }
}
[download]

for ($leetString) { # "loops" only once
  s/very/uber/g;
  tr/astloe/457103/;
  s!w!\\/\\/!g;
}
[download]

i didnt even catch the mistake at the beginning, i was just excited it worked i guess, glad you noticed tho loool xD

Here's some more unrequested advice:

for (1..$num) {
  open my $fh, '>', sprintf "temp%02d",$_; # temp01, temp02, etc.
  ...
}
[download]

Consider doing this if you plan to have more than 9 temp files and you want to keep them in numerical order. %02d will pad an integer with leading zeroes until it's two digits long. For more information, consult perldoc -f sprintf. You can even use a base-10 logarithm before the loop to figure out how many leading zeroes you would need, then insert that number into your format string.

EDIT: forgot that $_ is not implied with sprintf


$,=qq.\n.;print q.\/\/____\/.,q./\ \ / / \\.,q.    /_/__.,q..
"My life is like my typing: fast and full of mistakes."

Hello james28909,

Your use of $_ to generate the filenames “temp1”, “temp2”, ... “temp5” looks fine to me. There is, in general, nothing wrong with using $_. On the contrary, $_ is one of Perl’s strengths, because it facilitates the writing of concise, elegant code.

In the article you reference, apotheon recommends this rule of thumb for $_: If you have to use it explicitly, use something else instead. So far as I can see (I’ve only skimmed the article), the only justification given for this opinion is that:

a lot of people find $_ ugly and even obfuscatory.

Possibly true, but then they are people who don’t know and use Perl! Perl is, by design, an atypical language, so its idioms and byways are often unintuitive at first, but unfamiliar should never be mistaken for ugly. As apotheon notes, people who find Perlish idioms ugly sometimes avoid Perl itself for that reason. IMHO that is not necessarily a bad thing.

Hope that helps,

When using $_ keep in mind that it may change when you're not expecting it to. For example, if a sub gets called between setting $_ and using it, there's a fair chance that $_ will have changed. apotheon's rule of thumb is a good defence against that. Using a well named variable also has the huge advantage that it conveys intent which makes code more robust, easier to understand and easier to maintain.

In the OP's code there is pretty much no chance that $_ is going to change unexpectedly as it stands, but for clarity a loop variable helps:

for my $fileIdx (1 .. 5) {
    my $fileName = "$temp$fileIdx";

    open $file, '>', fileName  or die "Failed to create fileName: $!\n
+";
    ...
}
[download]

Perl is the programming world's equivalent of English

a lot of people find $_ ugly and even obfuscatory.

Possibly true, but then they are people who don’t know and use Perl! Perl is, by design, an atypical language, so its idioms and byways are often unintuitive at first, but unfamiliar should never be mistaken for ugly. As apotheon notes, people who find Perlish idioms ugly sometimes avoid Perl itself for that reason. IMHO that is not necessarily a bad thing.

I concur. And I'll submit that $_ is actually quite intuitive -- it's just other programming languages that are unintuitive, unfamiliar and (arguably) unnatural in this regard.

For me, $_ is simply the current topic that's being talked about. Like in natural languages, sometimes you leave it out entirely, since it's clear from the context what's being meant; sometimes you merely say "this" or "it" (which is how I read $_). Perl doesn't go quite as far as natural languages where you can have several of these at once, but on the other hand, unlike natural languages, Perl cannot afford to be ambiguous ("Bill met Bob. They talked, and he gave him back the book" is fine; the same thing in Perl wouldn't be).

Still, having one "topic" is better than having none, as most programming languages do. Natural languages are intuitive, after all, and we're all familiar with them.

For me, $_ is simply the current topic that's being talked about.

well, I think it is the problem. how about 2 topics happen at the same time? actually it's the biggest problem about $_ . think a topic you want to talk is the another topic (but happen at the same time).




---

---

I am trying to improve my English skills, if you see a mistake please feel free to reply or /msg me a correction

a lot of people find $_ ugly and even obfuscatory... Possibly true

It's about as true as the statement "Chinese language is ugly and obfuscatory". I mean, a lot of people find things like "舍阿奈比山是突尼西亞最高峰" completely unreadable... right?

actually perl's wild looking code is what brought me to perl, i like its hacky script look lol

Take a look at $_ in perlvar. Frankly, I don't hesitate to use $_. But then most of my code is fairly straight forward procedural code without much scoping challenge. I am sure someone here has run into an issue or two making use of $_, but I certainly have not.

I personally don't like the 'visual' of $temp$_, so would handle it differently, but I don't see anything functionally wrong with it.

just as an example, how would you do it differently if i might ask? :)

my $file = "file";
my $temp = "temp";

foreach (1..5){
   open $file, '>', "$temp" . "$_";
   print $file "THIS IS DATA";
}
[download]

or

my $file = "file";
my $temp = "temp";

foreach my $end (1..5) {
   open $file, '>', "$temp" . "$end";
   print $file "THIS IS DATA";
}
[download]

(not tested)

Personal preference only...

...the majority is always wrong, and always the last to know about it...

Insanity: Doing the same thing over and over again and expecting different results...

A solution is nothing more than a clearly stated problem...otherwise, the problem is not a problem, it is a facct

wjw

First with $_ then without

use Path::Tiny qw/ cwd path tempfile /;
## in cwd
path( "temp$_" )->spew("THIS IS DATA") for 1 .. 5;
## in $TMP directory
tempfile( 'tempjamesXXXX' )->spew("THIS IS DATA") for 1 .. 5;
[download]

Re^2: showing the error ,Can't modify concatenation (.) or string in scalar assignment, Perl::Critic::Policy::Variables::RequireLexicalLoopIterators - Write for my $element (@list) {...} instead of for $element (@list) {...}.
How to safely use $_ in a library function?
$_ functions vs argument-using functions
Implicit assignment to $_
What is the scope of $_?
the $_ Special Variable
Lexical $_ in given/when vs. BLOCK arguments
The $_ Special Variable
$_ getting clobbered by inner loop.
Auto-localization of $_ in while(<>)
What is using $_ ?
How to avoid $_ in grep
scoping/localizing of $_
global $_ behavior
$_ haters anonymou

open my $data, '<', "data.bin";
binmode($data);

read $data, my $buf, 0x1000000;

my $copy = "copy";

foreach (1..5){
    open my $file, '>', "$copy$_";
    binmode($file);
    print $file $buf;
}
[download]

open my $data, '<', "data.bin";
binmode($data);

my $chunk = "chunk";

foreach (1..5){
    open my $file, '>', "$chunk$_";
    binmode($file);
    read $flash, my $buf, 0x200;
    print $file $buf;
}
[download]

my $file = "file";
my $temp = "temp";

foreach (1..5){
open $file, '>', "$temp$_";
print $file "THIS IS DATA";
}
[download]

Whatever you may think of the use of  $_ this code doesn't compile under strictures because  $file is not undefined. Quoth the open docs (emphasis added):

If FILEHANDLE is an undefined scalar variable (or array or hash
element), a new filehandle is autovivified, meaning that the
variable is assigned a reference to a newly allocated anonymous
filehandle. Otherwise if FILEHANDLE is an expression, its value
is the real filehandle. (This is considered a symbolic
reference, so "use strict "refs"" should *not* be in effect.)

c:\@Work\Perl\monks\james28909>perl -wMstrict -e
"my $file = 'file';
 my $temp = 'temp';
 ;;
 foreach (1..5){
   open $file, '>', qq{$temp$_};
   print $file 'THIS IS DATA';
   }
"
Can't use string ("file") as a symbol ref while "strict refs" in use a
+t -e line 1.
[download]

(Talk about rearranging the deck chairs on the Titanic! :)

yeah i had caught that earlier lol. i removed the first reference to the "file" and added "my $file" in the loop.

and thanks to everyone for the valuable input.

need more input hehe

I’d go with foreach my $var (1..5) every time, for the very same reason that “I don’t like to see the same global variable-name being used again and again.”   Especially not, as in this case, one that you can’t see.

Okay, so it works okay now.   Goody,goody, but then someone comes along and needs to make a truly-slight change ... which just happens to consist of some other control-structure that changes the meaning and value of $_.   Now, they have to dance-around your program, making a bunch of source-code changes (entirely unrelated to what they wanted to do ...), just to do what you could well have done the first time.   (And, to keep things realistic, let’s say they inadvertantly miss just one thing ...)   Meh.   That sort of thing is “just not worth the clever.”

Keep it simple ... keep it maintainable.   I’m not laying-down any sort of commandment here, but it is trivially easy (as shown) to create a very nice, named, locally-scoped variable, associated with the loop and existing only within its scope, that contains the value of the loop index.   That’s one of Perl’s nicest, most pragmatically useful features.   (As is $_, yes, in small doses ...)

I think the biggest maintainability problem with $_ is accepting it as a default without using it. We are forced to remember every place it can be used in this way.
Bill