JumpStart Live Day 4: Exercises

JSL Day 4 includes only one exercise:  A password verification program!

My program follows this structure:

• while loop (continues as long as variable confirmed is false)
  • until loop (continues until password meets requirements)
    • Multiple if-statements (tells user what they did wrong)
  • if-else-statement (user input determines if while loop breaks or continues)

Below is the first part of my program.  You can see the following:

• Assignment of user input to variable password
• Start of the while loop (which runs as long as confirmed evaluates as false)
• Entire until loop (which runs until password meets all the requirements)

Assigns user input to “password”, starts while loop, and uses until loop to evaluate password.

Let me break this down into smaller parts…

First, user input collection:  Outside of any loops, I prompt the user for a password.  User input is assigned to variable password.

Next, I set a new variable — confirmed.  It’s initialized with a value of false.  (This is important for the while loop below it.)

Looping the program

I needed my program to do the following:

• Evaluate whether password meets all criteria
• Keep prompting user for password until it meets all criteria
• Ask user to re-enter their password
• Start the whole process over if the re-entered password doesn’t match the original

Simply put, my program’s end goal is:  Get the user to enter the same, approved password twice.

My confirmed variable will only switch over to true if the user successfully meets this goal.

That’s why my larger while loop hinges on confirmed — and whether it’s true or false.  Basically, I’m telling Ruby:  “As long as confirmed stays false, keep running this program.”

Evaluating user input

My first step is evaluating whether password meets all the criteria.  (In fact, I actually wrote this part first!)

An until loop keeps running until password has at least:

• Eight characters
• One number
• One symbol
• One uppercase letter
• One lowercase letter

Because there are so many boolean statements, I indented them for readability.

(Note:  I made sure to leave logical operators at the end of each line.  Why?  So Ruby knows to keep going for more boolean statements.)

How my program evaluated user input:

Does password have at least eight characters?
Evaluates whether password.length is greater than or equal 8.

If it evaluates as true, then password has at least eight characters.

Does password have at least one number?
Uses =~ method on password with /\d/ as the argument.  (Found this here.)

If it evaluates as true, then password has at least one number.

Does password have at least one symbol?
Individually evaluates each possible symbol by calling the .include? method on password, and entering its respective symbol as an argument.

I only need one symbol.  Or (||) only needs one statement to be true.  If one of them is true, then the whole statement to evaluate as true.

When that happens, it means password has at least one symbol.

Does password have at least one uppercase letter?
Uses =~ method on password with /[A-Z]/ as the argument.  (Found this here.)

If it evaluates as true, then password has at least one uppercase letter.

Does password have at least one lowercase letter?
Evaluates whether password is equal to password.upcase.

If it is NOT equal, then the statement returns true.

(Note:  I wanted to use =~ like I did for the uppercase condition…but couldn’t find anything for it.  This was the other solution I came up with.)

WHEW!  That was a lot to comb through!

Operator “and” (&&) requires ALL adjoining statement to be true.  So until the above conditions are ALL true, then the loop will continue prompting the user for another password.

Aaaand here’s what that looks like:

Checking whether “password” meets our criteria

Alright, so what if the user needs to re-enter a password?  How will they know what they did wrong?

Through the power of FRIENDSHIP?  No!  The power of if-statements!

A series of if-statements a) figures out what the user did wrong, and b) prints a message telling them what they need.

Here’s what that looks like:

Telling the user what they did wrong (if their password didn’t meet the criteria)

Why did I use five if-statements?  Why not if-elsif-else?

(Geez, does Jansen really love if-statements that much?  Close, but not quite!)

Our user will most likely botch up multiple things in their password.  In other words, we need the flexibility for multiple conditions to evaluate as true.

In an if-elsif-else (or if-elsif) block?  A totally different story.

How come?  Because the second our program comes across one true statement, it’ll drop the whole thing like it’s hot!

This behavior is also known as short circuit evaluation.

The if-statements are checking for passwords that do NOT meet the criteria.  As a result, my conditions are generally an inversion of my first set of boolean statements.

Here’s an example:  Unlike before, we’re not checking if password.length is greater than or equal to 8.   Instead, we’re now checking if password.length is less than 8.

These if-statements determine which messages (if any) are shown to the user.

After that, the until loop these statements are nested under prompts the user to try again.

Getting a new value for “password” if the user’s password doesn’t meet the criteria

New user input is assigned to variable password.  The until loop once again checks to see if the new string meets our criteria.

Here’s what that looks like:

 

Sample run: Collecting input until all conditions are met

Verifying the password

So our password meets all the requirements established in the until loop.  Great!

Now we just have to “verify” the password…by prompting the user to enter their password a second time.

If they successfully type the same password a second time, the while loop breaks (and the program ends).

Here’s how that works:

Verifying the user’s password (by making them enter it a second time)

First, we prompt the user to re-enter the password.  The input is assigned to a new variable called confirmation.

If confirmation has the same value as password, then it prints a congratulatory message for the user.  Variable confirmed switches to true, and the while loop breaks (since it runs as long as confirmed is false).

Otherwise, we tell the user that they didn’t succeed.  After prompting them to enter another password, we assign it to variable password.

Our program throws it back to the beginning of the while loop, which kicks it down to the until loop for evaluation.  The cycle begins anew!

Here’s what that looks like:

Sample Run: Verifying password

 

Summary

This exercise let me practice working with nested loops, loops with logical operators, boolean zen, and if-statements.

Cool things I learned from JSL Day 4:

In no particular order:

• Boolean zen is another way of saying “writing clean, concise boolean statements”.
• A good rule of thumb:  Never compare a variable to true or false
• Fencepost problems require an extra line of code outside of the loop

References

• How to check if a string has at least one number in Ruby [Stack Overflow]
• How to check if a string contains uppercase characters in Ruby [java2s.com]