Because its value is undefined.

Update: And I don't that's good practice when we're going to change its value with an increment operation in a following loop.

Because its value is undefined.

Personally, I think that's a good thing.

That way, if I try to use it -- like print it -- before I've done something sensible with it, I get a nice friendly message telling me so; rather than an mysterious zero that shouldn't be.

If only C had a non-zero, non-null value that variables got implicitly initialised to.

---

Anyone got any experience of this phone's predecessor?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

what makes it better to change that value from zero than from undefined?

The way forward always starts with a minimal test.

Well, I can't remember what is supposed to happen with Perl, but it definitely isn't something a C/C++ coder would do. And it will look better when it's revisited years later. I haven't tried the idiom as the OP has it. Doesn't Perl squawk about the variable being undefined if using strict?

Update:

Thanks, 1nickt. Here is the explanation I was looking for (from p. 72 of Perl 6 Now: The Core Ideas Illustrated with Perl 5 by Scott Walters):

Perl 5 throws you a Use of uninitialized value when you try to use a variable that contains undef, at least for most operations. use strict; use warnings; my $i; $i++; is acceptable; it was decided that trying to increment undef obviously means that undef should be interpreted as 0 and is common enough not to require explicitly declaring the variable. String operations, bitwise operations, and most math operations will throw this warning.

So the idiom is okay and will not cause a squawk, but I still maintain that, in code to be shared and used by others, one should initialize the variable, and I think Damian Conway would agree it is a best practice (I'll see if I can find a reference to this situation in his book).

Update 2:

I couldn't find anything specific, so I can't fairly claim a Conway best practice, but I still claim explicitly initializing the counting variable adheres to Prof. Conway's goal of Maintainability where he says, among other things,

...Better yet, try to optimize for comprehensibility: easy-to-read and easy to understand aren't necesarily the same thing.

I shall try not to complain about the iterated-undefined-index-variable idiom again, although I will continue to initialize it in my code as a personal best practice.