Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: Remove blank lines from REGEX output

by sundialsvc4 (Abbot)
on Feb 05, 2014 at 21:13 UTC ( #1073607=note: print w/replies, xml ) Need Help??

in reply to Remove blank lines from REGEX output

FYI, if you only want such a loop to consider certain lines within the file, a rather handy “Perl-ism” would be a line that looks like this:

next unless $data_line =~ ...whatever... ;

... followed by whatever else you might need in the loop.   The loop will immediately proceed to the next line, unless the line matches the particular condition, and thus you avoid having to write a rather large and bulky if-statement that encompasses the rest of the while block.   Plus, it reads easily ... it’s a very human-natural way of saying it.

  • Comment on Re: Remove blank lines from REGEX output

Replies are listed 'Best First'.
Re^2: Remove blank lines from REGEX output
by Deep_Plaid (Acolyte) on Feb 05, 2014 at 21:32 UTC

    Thanks, Sundial. I prefer more human readable approaches.

      I think that you are wrong on that. The next approach is very human readable and and a very efficient way to build a decision tree in many cases. Suppose that you have a set of business rules specifying which lines of a file you want to process and which you want to discard. You can do it this way:
      while (<$IN>) { chomp; next if /^#/; # discard line, it is a comment (starts + with #) next if /^\s*$/; # discard line, contains only spaces next if length < $min_length; # line is too short next if /^REM/; # another form of comment next unless /^.{3}\d{4}/; # lines of interest have 4 digits from +position 4 to 7 # now the real processing ... }
      This is much cleaner and much more readable than a long series of nested if ... elsif ... elsif ... It is also often quite efficient, because as soon as you discard a line for one reason, none of the subsequent tests has to run (of course, it will be more efficient if you are able to put first the most common causes for exclusions and last the rare ones). There are other ways of achieving similar results. For example, you could have:
      while (<$IN>) { chomp; next if /^#/ or /^\s*$/ or length < $min_useful_length or /^REM/ + or not /^.{3}\d{4}/ ...
      This is more concise, and any condition evaluating to TRUE will also lead to short-circuiting the subsequent conditions, so that the performance will be similar, but that removes the opportunity to document the business rules that led to exclusion. I might use any of the two techniques, depending on the situation, but if the business rules are somewhat complicated or numerous, I prefer the first one.
        next if /^#/ or /^\s*$/ or length < $min_useful_length or  /^REM/ or not /^.{3}\d{4}/ ...
        ... that removes the opportunity to document the business rules ...
        next if /^#/ # document this or /^\s*$/ # document this too or length < $min_useful_length # and this one or /^REM/ # and so on ... or not /^.{3}\d{4}/ # ... ... ;

        ... but I am sometimes very (unpleasantly) surprised by interactions between the very lowest level | precedence logical operators and other expressions (but I can't seem to come up with a good example), so maybe individual statements are better after all.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1073607]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (14)
As of 2017-10-18 13:38 GMT
Find Nodes?
    Voting Booth?
    My fridge is mostly full of:

    Results (244 votes). Check out past polls.