Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^5: Remove blank lines from REGEX output

by Laurent_R (Canon)
on Feb 06, 2014 at 11:02 UTC ( [id://1073688]=note: print w/replies, xml ) Need Help??


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

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.

Replies are listed 'Best First'.
Re^6: Remove blank lines from REGEX output
by AnomalousMonk (Archbishop) on Feb 06, 2014 at 11:51 UTC

    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?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1073688]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2024-03-19 09:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found