Last week, two cohorts and I were assigned to create a CLI application. One concern was what would happen if the users typed the wrong input while interacting with our application. We wanted an interface that could deal with users “who can’t read good and wanna learn to do other good stuff too”. We wanted to make sure typos will not lead to any errors that could break our code, leading to users to exit our application involuntarily.
We decided to go with “if …elsif …else” loops to give our users an illusion of choice. This particular loop will allow certain inputs, but will not blow up the application if there are typos. We ended all loops at the “else” clause referencing the loop itself, so it would spin back up for any undesirable inputs
As we added more functionality to our application, our methods got longer and we needed more “else if” statements. We had to ask ourselves, do we want to repeat this process over and over for every new functionality that we add. We did…not.
Our loops were calling loops and we had loops inside loops calling other loops. We had a full-blown “Loopcetion” problem.
One of my brilliant partners, E, a master of sorts (parlor tricks mostly), finally said, “we just need a simple menu for our users to navigate to and back from”. After searching around for a solution, we happened into an “until…end” loop that suited the menu purpose. All we had to do was to write a line of code for each “action” that our users can potentially make. We gave our users a safe word, “exit”, which will allow them to leave our menu at any time. Our users can type as many wrong words as they want inside this “menu” world. Our safe word will allow them to leave this world. They can also type other keywords to travel to other worlds from this menu world.
The “until…end” loop worked especially well if the results of the other methods did not matter to our menu loop. The menu loop was suitable for the purpose that we assigned it to have. We still had reliable “if..else” loops that were designed by the brilliant Jenn that did not need to be replaced.
The lesson that we learned, was that different needs called for different methods. We need to pick the most applicable method for each situation. Learning to deal with situations that arise and applying the best method to any given situation is part of the process, the process of being a better programmer. Here’s to learning a little bit more every day!
Best Regards,
James Wu
