Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Re^4: Remove blank lines from REGEX output

by AnomalousMonk (Chancellor)
on Feb 06, 2014 at 00:22 UTC ( #1073634=note: print w/replies, xml ) Need Help??

in reply to Re^3: Remove blank lines from REGEX output
in thread Remove blank lines from REGEX output

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.

Replies are listed 'Best First'.
Re^5: Remove blank lines from REGEX output
by Laurent_R (Canon) on Feb 06, 2014 at 11:02 UTC
    Well, yes, sure, you can still document your rules this way, but then you loose the concision. In that type of situation, I usually prefer a series of individual next statements (as you said, less risk of operator precedence mistakes). I would use the more concise form with several or only when the rules are more or less obvious or self-documenting. For example, in a procedure where I wish validate a date format, I could possibly have something like this:
    next if $day_in_month !~ /^\d\d?$/ or $month_nr !~ /^\d\d?$/; # one or + two digits next if $day_in_month < 1 or $day_in_month > 31 or $month_nr < 1 or $m +onth_nr > 12; next if ...
    Although this is a somewhat silly example, as this is certainly not good way to validate a date (it would not reject 31 Feb., for example), but it could still be useful in some cases to check the date format (do I have, as expected, dd/mm/yyyy or is it something else such as mm/dd/yyyy, yyyy/mm/dd or still something else), or to check that this piece of data is really likely to be a date and not, say, some numbers representing something else such as, say, a phone number, an IP address or whatever.

      One can also take another tack and use a series of statements like

      next if not proper_year($year); next if not proper_month($month_nr); next if not proper_day($day_in_month, $month_nr, $year);

      which might be said to offer the best of both concision (it's self-documenting, or can be made so) and encapsulation (annual, monthly and daily proprieties defined in one place in their respective validation functions). This sort of approach is what I usually prefer if I have the opportunity to take a second pass at a program and consolidate.

      Then there's the OO approach...

        Yes, you are right, this is probably better. As I said earlier, my example was not given as a proper way to validate dates, but only as an example of rules that are self-documenting or obvious to anyone and thus don't really need any comments

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2018-06-23 01:46 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.