gistfile1.md

Context: CodeAcademy asked for code like:

var = gets.chomp
var2 = var1.capitalize
var.capitalize!

#...

Why are they making a new variable in these lines of code? You can totally delete the lines with the first_name2 et. al. and not change the final product. The program runs and it properly capitalizes the first name. I think Sharon was right that the two lines of capitalize code were redundant. You can delete out the first one (the one with the new variable) and the program runs fine with properly capitalized output. You can delete out the second capitalize line (the one that's first_name.capitalize!), change the variable reference in the output lines (from #{first_name} to #{first_name2}) and the program runs with the same finished result (I'm reasonably sure that I tried it and it worked). If it were me and I was trying to be economical with code lines, I would lose the line that creates a second variable. Why might one want to create that variable? Was it just a pedagogical thing that code academy is doing to teach me the variety of commands or is there some other reason?

This is somewhat confusing to be honest. You don't need your variable_2 variables in the above code for it to work. But... there are reasons to "double store" data in some cases. Programmers will talk about "normalization" of data, meaning to take input of various formats and convert them into a ubiquitous format used all over in an application. Sometimes that normalization is actually destructive, e.g. once you do it you can't go back. In those cases you may want to store the original data because there is also some use for the original form of the data. I have two real examples from real code:

1: People's names are hard. Often a program will ask you to input your first and last name, but will present a "Full Name" all over. In Ruby you could have something like the following:

first_name = gets.chomp
last_name = gets.chomp
full_name = first_name + " " + last_name

But... getting back to first and last name from full name is not as simple as it looks at first blush. You might start with

new_first_name, new_last_name = full_name.split(' ')

but... what if your original first name is "Dino" and your (given!) last name is "Dai Zovi" (not the space). When you try to above split code new_first_name is "Dino" and new_last_name is "Dai" (without the "Zovi"). There are some tricks you can attempt. For example #split (we use the "#" to indicate it is a method called on an object in Ruby. Just tuck that away for now) takes more parameters than the character to split on, but you can limit the number of returned strings so you could try

new_first_name, new_last_name = full_name.split(' ', 2)

That would set new_last_name to "Dai Zovi"! Success! Unless.. if you have a compound (un-hyphenated) first name (I've never seen this but bear with me) like "Super Cool" and single last name "Person" then the above code would set new_first_name to "Super" and new_last_name to "Cool Person" which is still wrong. By storing both the original input and the computed full_name you avoid all of these problems.

2: Recently I found this in The Real World. I have 401ks in Fidelity. When I login I have a super long and complicated alpha-numeric-special-character'd password. Literally 20 characters. On their website, if I mistype a single character I can't login. When I called their phone support it asked for my password and provided instructions saying that I could just push the number that corresponds to any letters and # for any special characters. This means that when I created my password for their online site the stored a second password for phone access computed from the original. That algorithm is destructive because it means that the characters "A", "B", "C", "a", "b", "c" and the number "2" must all be mapped to the same place. (and the same for every other button on the keypad and for special characters to go to '*' or '#'). One could hypothesize that they do this in real-time right, grab a bunch of numbers from the phone, take the password out of the database, then compute (based on the password) the numeric code it should be. It turns out that financial regulations (and general website security best practice) say that you cannot store passwords in a database. They must be one-way encrypted (so that if the database is stolen, the thieves don't know your password). So combining those two details it turns out they store your password twice, in two different formats, because computing one is destructive.