in reply to Validation of UserInput is a positive Integer or not?

Short answer: NO, not even close!

Longer answer: 

#!/usr/bin/perl
use strict;
use warnings;
# 1149595

print "Enter number of days (1..90, no fractions or negative values): 
+";
my $days = <STDIN>;
chomp $days;

# if ($days =~ /^\s*1-90-9*\s*$/) {   # the numeric "test" is hopeless
+ly wrong
                    # the "^\s* allows user to enter leading spaces
                    # regex permits a trailing space to match despite 
+the chomp
                    # ....BUT, a regex is probably the wrong way to go
+...

#if (0 < $days && $days <= 90 && $days =~ /^\d\d$/ ) {     # makes the
+ exact test explicit
if ( (0 < $days) && ($days <= 90) && ($days =~ /^\d\d$/) ) {  # some m
+ay prefer this
    print "Inside if, satisfied the spec: $days \n\n";
    } else {
    print "Days entered do not meet spec: $days \n\n";  # tell the use
+r specificly
}

[download]

Update Added missing "use strict;" --- aaaerg! (and fixed misallignment of some comments).


check Ln42!

Replies are listed 'Best First'.
Re^2: Validation of UserInput is a positive Integer or not?
by Apero (Scribe) on Dec 07, 2015 at 19:27 UTC

    I'd suggest a couple minor changes to update this line in your original version: 

    if ( (0 < $days) && ($days <= 90) && ($days =~ /^\d\d$/) )

    [download]
    with this one: 
    if ( ($days =~ /^\d+$/) && (0 < $days) && ($days <= 90) )

    [download]

    This avoids printing a warning of Argument "x" isn't numeric in numeric lt (<) by doing the regex test first (consider what the code does with an alpha-string.) Further, the original regex disallows values like "1" which are within the desired spec. No real harm in allowing any number of digits since the later tests verify the range, although using a repeat of {1,2} could also work (I personally try to avoid it as it makes updating the range in the future more complex.)

[reply]
[d/l]
[select]

      Apero offers a valid and valuable learning point in suggesting that the order of the tests be changed.

      But (in an exchange via CB) Apero cites the possibility that an idiot responding to a prompt asking for integers between 0 and 91 with "hi" will cause perl to "spew warnings." I disagree with the view that this is a bad thing in this case.

      In fact, the issuance of warnings might (well, not likely, but "might") cause my not-entirely-hypothetical idiot to actually read the prompt, once that's written in a manner which makes the required input explicit.

      And, while I'm (politely, I trust) disagreeing with fellow Monks, the notion of adding a prompt module from BillKSmith is also, IMO, a valid teaching point, but an unnecessary addition to overhead, because OP's intent (as stated in the narrative) is simply validation of an input. Further, since OP's code - were it corrected as ExReg suggests or as modified in my note - does the same job, inline and very clearly for any future reader or maintainer.

      Fixed: missing char and extra close tag


      Spirit of the Monastery


[reply]
[d/l]
        In fact, the issuance of warnings might (well, not likely, but "might") cause my not-entirely-hypothetical idiot to actually read the prompt, once that's written in a manner which makes the required input explicit.

        This largely depends on the user audience. Some Perl I write is customer-facing and warnings from the interpreter (be it Perl, Python, or extra debugging printf or println statements in C or Java) are very frowned upon when you're writing code customers will use. Techniques like defensive programming and encapsulating errors really does make a difference when you're writing well-designed, professional code. Granted not all projects require such attention and polishing, so perhaps this was what you were getting at.

        I take a fairly strict approach to untrusted input in that it needs to be correctly validated, and I know my audience might not even care to read a line of Perl to use my program. Cluttering the screen of someone who may have simply made a typo with technical jargon (as much as it helps those of us who write Perl) does not increase usability if the error message is well-written, and in fact decreases usability by cluttering the screen with information not all users will be able to understand. If more direct description is required, the error message handling such bad input should be improved.

[reply]

In Section Seekers of Perl Wisdom