In Perl Best Practices (PBP) section 5.2, there is talk of initializion but only in the context of locals:my $retval = 0; my @list = (); my %hash = ();
"Even if you specifically did want that variable to be undefined, it's better to say so explicitly: ... That way any readers of the code can immediately see that the lack of definition is intentional, rather than wondering whether it's an oversight."What about the general case? Arguably, it's not of much significance in perl compared to other languages since your data will just get the value undef, but I'd rather not have to deal with undef or all the defined() checks on variables. I'd rather just assume, in my own code at least, that something undef indicates a problem somewhere. During a recent code review this issue came up, and a fellow co-worker argued against this practice because:
Outside subroutines, there's a big difference. As package variables, the assignments happen at certain times. For example, you have a package variable that gets assigned in a subroutine. You have no idea when that subroutine is called; it can be called from a BEGIN {} block. Then later, if you have that package variable assigned during a regular block, the values get overriden by my @var = ();. The = () happens during the normal execution time but the my @var exists before the BEGIN block so you end up wiping out everything you put in your package variables this is really bad if you're doing inside-out classes.Putting aside the issue of whether one ought to be using inside-out classes, what do you perl monks find to be the best practice?
In reply to Use of uninitialized variables? by Zadeh
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |