Re^2: Use of uninitialized variables?

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.

Comment on Re^2: Use of uninitialized variables? Select or Download Code

Replies are listed 'Best First'.
Re^3: Use of uninitialized variables? by GrandFather (Saint) on Jun 11, 2008 at 23:10 UTC
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]
Re^3: Use of uninitialized variables? by chromatic (Archbishop) on Jun 12, 2008 at 06:39 UTC
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]