in reply to Looking for less code

First, I would improve the indentation: 
while ($line = <DATA>)
{
     if ($line =~ /WNT/ || $line =~ /UNX/)
     {
          print "$line\n";
     }
     
     if ($flag)
     {
         if ($target_db ne 'sql')
         {
             next if ($line =~ /$target_db/i);
         }
         else
         {
              next if ($line =~ /informix/i || $line =~ /oracle/i)
         }
         
         print $FH "$line";
         if ($line =~ /$target_os/)
         {
             undef $flag;
             next;
          }
      }
        
      if ($line =~ /UNX/ || $line =~ /WNT/ || $line =~ /COMPONENT/)
      {
          if(!(defined $flag))
          {
              $flag = 1;
              print $FH "$line";
          }
      }
}

[download]
This is probably wrong: 
if ($line =~ /UNX/ || $line =~ /WNT/ || $line =~ /COMPONENT/)
{
    if(!(defined $flag))
    {
        $flag = 1;
        print $FH "$line";
    }
}

[download]
In a code like this, 
if ($line =~ /$target_os/)
         {
             undef $flag;
             next;
          }

[download]
NEVER, repeat NEVER fiddle fiddle around with undef as a "false" value (except in rare cirsumstances). If you mean that $flag should be "false", set $flag to "0 (zero)". A simple rationale is that if you want to print $flag for debugging, "undef" is an error. Another rationale would be that you KNOW that it is "false" not "undefined"!. So say so!

the above code is hard for me to understand your intent. Can you post some set of data and the "pass" and "fail" cases? That would be most helpful.

Replies are listed 'Best First'.
Re^2: Looking for less code
by moritz (Cardinal) on Aug 11, 2009 at 08:08 UTC
    A simple rationale is that if you want to print $flag for debugging, "undef" is an error

    How come? Last I looked it was a warning, and only if warnings are enabled.

    Additionally it's a good idea to use Data::Dumper or something similar for debugging output anyway, so I don't see the point you're trying to make.

    Another rationale would be that you KNOW that it is "false" not "undefined"!. So say so!

    undef is also false - why would 0 be clearer false than undef? 0 is a number to me, not primarily a "false" boolean value.

[reply]
      Point 1: You should run with both "warnings" and "strict" enabled.

      Point 2: I recommend taking some 'C' classes and you will understand the difference between "undef" and "zero".

      Update: My comment about 'C' was not meant in a derogatory way. I stand by my assertion that code should run with both warnings and strict. Some performance increase can be obtained without warnings in well debugged code. But that was not the point here. There is a difference in general between, I know for sure that this $var is "false": ('',"",0) and I "don't know what the value is", (undef), so I am gonna assume "false".

      Update: minor typo punctuation corrections. 

      #!/usr/bin/perl -w
use strict;

my $x = undef;
print "$x\n";
$x = 0;
print "$x\n";

#prints: 
#Use of uninitialized value $x in string at C:\TEMP\perl1.pl line 5.

0

      [download]
[reply]
[d/l]
[select]
        Point 1: You should run with both "warnings" and "strict" enabled.
        I know. Still it's not an error, and still you should also use Data::Dumper (or better) for debugging (and then you don't even get a warning). But didn't I say that already?
        Point 2: I recommend taking some 'C' classes and you will understand the difference between "undef" and "zero".

        How do C classes help me here? To understand that an undef doesn't create an IV?

        I also know the difference between 0 and undef in perl. How does that relate to my second point? Both evaluate to false in boolean context, without warning.

[reply]
[d/l]
        I recommend taking some 'C' classes and you will understand the difference between "undef" and "zero".
        Unlike C, in Perl, "undef" is actually a value. I really fail what insight C can give you here. In fact, I recommend you take some Perl classes, and learn what undef really is (and isn't).
[reply]
[d/l]

In Section Seekers of Perl Wisdom