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.
| [reply]
[d/l]
[select] |
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...
| [reply]
[d/l] |
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
| [reply] |