In your first example, $var is declared inside the if block, but exists ONLY within that block. Since it's undefined when program_flow encounters the print statement, strict pumps out the error.

On the other hand, in your example 2, "my $var" is in scope throughout the code you show.

Careful with my $var if $condition. From perlsyn:

NOTE: The behaviour of a "my" statement modified with a statement modifier conditional or loop construct (e.g. "my $x if ...") is undefined. The value of the "my" variable may be "undef", any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Thanks xdg. I won't use. I saw something similar in an existing code and I was surprised that it works. Hence I decided to prod a bit.
Regards,
Ranjan

The second example is also buggy and shouldn't be used. Declare the variable in the previous line. The bug is that the runtime effect of my() is avoided when the condition fails.

my $var;
$var = 'ok' if @_;
[download]

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Thanks ww.
Since the second example works fine which means that even though the expression is not executed because of the condition being false, still the variable is declared. Is it like the perl interpreter first parses the code for the declared variables and their scope and then starts executing the code?
Regards,
Ranjan

Note, however, that if you had warnings on (use warnings;), you would have seen something like this when executing example 2:

Use of uninitialized value in concatenation (.) or string at ./test.pl
+ line 5.
[download]

This is because you refer to a value ($var) which, while it is within the current scope, has never been set to any value (it is still undef). I find that such warnings are often an indicator that my code is doing something I don't expect or haven't prepared for.

Also note that it is possible to declare a lexical inside the parentheses of the "if with a block" which leads to an interesting variation of the scope theme:

use strict;
use warnings;

my @L = ('1', '0', '');

while (@L) {
    if (my $x = shift @L) {
        print "\$x is true: <$x>\n";
    } elsif (length $x) {
        print "\$x is false: <$x>\n";
    } else {
        print "\$x is still false<$x>\n";
    }
    # print "$x\n";    # yields a strict error when uncommented
}
[download]

Which prints:

$x is true: <1>
$x is false: <0>
$x is still false<>
[download]

You see that the scope of that lexical is all the way down to the closing curly of the last appendant else-block.

Though it seems the declaration of $x is outside of the if-elsif-else-blocks, its scope actually is only the (complete) conditional.
Uncommenting the print statement outside the conditional yields the "strict vars" error again.

The two bracets make up an extra namespace

I would avoid calling this a "namespace". The brackets in this example are creating a lexical scope. When someone says "namespace" in Perl, they almost always mean a package.