in reply to Use of uninitialized variables?

Best practice is to always use strictures, declare variables to minimize their scope and initialize scalars with a useful value at declaration time (except where conditional initialization is required).

Never initialize a scalar variable with a 'junk' value just to shut up warnings! The warnings give you a heads up about bugs in your code.

undef is a vitally important variable state that allows a lot of sanity checking that otherwise is difficult to achieve. Strictures are your friend, perhaps even a best friend.

Note that arrays and hashes don't need to be "initialized". They start empty in any case so something of the form my @array = (); is redundant.

Perl is environmentally friendly - it saves trees

Replies are listed 'Best First'.
Re^2: Use of uninitialized variables?
by Zadeh (Beadle) on Jun 11, 2008 at 22:40 UTC
    OK, so for arrays and hashes there is no need. This is just about scalars then.
    I certainly don't advocate initialization for it's own sake simply to shutup warnings about uninitialized variables.

    An idiom I like to use in subs where something like: 
    sub foo {
  my $retval = 0;
  <... lots of code here ...>
  return $retval; # This is the only return in the sub
}

    [download]
    I like to use this for several reasons

    1) It's guaranteed that the sub will always return a value.
    2) There is a single entry/exit point. Apart from it being simple, I know that this makes it easier for compilers/interpreters to prove certain things about your code. Can't say I know if it will make any difference whatsoever in Perl, but it often does in C-like languages.
    3) The initial value of 0 is assumed to be the failure case, putting the burden of 'proof' to set $retval properly. Hope to see a failure case quicker this way.

    When possible, I also prefer to see code more like: 
    ...
my $whatever = some_sub();

    [download]
    I find the 'classic C' style of declaring lots of variables at the top of your routine, then using them in the body, to be harder to follow. e.g.: 
    my $var1;
my $var2;
my $var3;
my @list;
my %hash;
...

    [download]
    Worse if they're all global! I don't like jumping back and forth, or wondering where variables got their values (or what they were initialized as/from). Arguably if the code was done well enough in the first place it would already be pretty short and there would be no problem, but unfortunately I see this all the time. IMO it's more error-prone. If that's what you mean when you said "declare variables to minimize their scope" then I agree.
[reply]
[d/l]
[select]

      I like to use early exits because they often save a lot of obfuscating indentation and state management. Test simple cases first and exit early. Complicated cases then tend not to be indented and the conditions that get you to the complicated case are generally much easier to see. Note that this early exit technique works in the context of loops just as well as it does for subs.

      To me a single point of exit seems a rather artificial constraint that often requires extra testing and nesting to achieve. Removing that constraint very often allows much clearer logic flow - it's easier for people to understant and prove, which is much more important than making it easier for compilers.

      Using undef as the failure case allows 0 to be used as a valid return value. That was part of what I was alluding to in the paragraph about "sanity checking".

      C required that all variables be declared at the start of a block. C++ and Perl (to name but two) allow variables to be declared wherever they are needed. So yes, I did mean to take advantage of that feature of Perl (and other languages) to declare variables as close as possible to their first use.

      Perl is environmentally friendly - it saves trees
[reply]
      There is a single entry/exit point. Apart from it being simple, I know that this makes it easier for compilers/interpreters to prove certain things about your code.

      Maybe for a really stupid compiler, but I have trouble believing any modern optimizing compiler has trouble with escape analysis of this sort these days.

[reply]

In Section Seekers of Perl Wisdom