Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^5: Remove blank lines from REGEX output

by Laurent_R (Parson)
on Feb 06, 2014 at 11:02 UTC ( #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.


Comment on Re^5: Remove blank lines from REGEX output
Select or Download Code
Re^6: Remove blank lines from REGEX output
by AnomalousMonk (Abbot) 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
Node Status?
node history
Node Type: note [id://1073688]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (3)
As of 2014-10-25 03:19 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (141 votes), past polls