Usage

The Contacts Project did not really have sufficient instructions in the README. It did not include any compilation/execution information, which I initially assumed was not a big deal since it is a python program. So, once I had cloned the repo, I tried to run the program with the executable python file. Unfortunately, this produced an error saying that I needed a contact book yaml file to run the program, but there was no such file included in the project folder.

I decided my review wouldnt be very helpful if this issue is the only feedback I provided, so I decided to look at the source code and see where this error was produced in the code and why I was getting it. I found in the code that this error is produced if the user does not provide a contact book file in yaml format as an input argument. I then returned to the directory and added a blank file with a yaml extension, guessing that the program would add to and edit this file during execution. Running the program with this blank file was also unsuccessful. Upon further research within the source files, I found that the input file is read and processed right away, so a blank yaml file caused an error. So, suggestions 1 and 2:

1. Include execution instructions in the README file to let the user know that a command argument of this type is required.
2. Include a correctly formatted yaml file with the rest of the project files based on how the program processes the file, or allow the user to start from scratch and create a completely new address book with a blank file or no file.

I think the idea of importing a pre-existing list of contacts is a great idea so a user would not need to manually enter them all into a new one, but in this particular situation when peers are running and reviewing the program, it ends up causing some confusion since no file was included and we are unaware of the requirement/formatting for the file since it is not described in the README.

I still did not want to leave the review without actually getting to provide any feedback on the program operation since Im sure thats what the authors are really hoping to get. So I further examined all of the source files and how the information in the yaml file is processed, including which keys are required fields, and created a simple yaml file containing one contact with all of the required information. Using this file as the command line argument proved successful when running the program.

So, most of the program worked the way it was supposed to and the help aspect was really useful in describing all of the available operations since they werent described in the README file. In terms of things that I would change, here are my remaining suggestions:

1. Include the information printed by the help command in the README file so the user knows possible operations
2. When searching by name, adjust the program to be case insensitive (otherwise it says there where no results found if the case does not match exactly)
3. If a command is input incorrectly (i.e. search <name> without the first or last identifiers) crashes the program - implement error checking and provide a useful error message instead

Everything else worked correctly. I liked the add function since it asks for all of the numbers individually after the name is given - that made it feel easy and organized. I also thought that all of the printed information was formatted really nicely.

Style

I did find the code to be well organized and easy to follow, as well as being modular. My early investigation of the code in order to figure out how I could get the program to run was relatively easy because of this. Most functions and processes were well separated without placing too much bulk in one area. Despite the issues I faced using the program, I do think the code is well written and organized in terms of style

Philosophy

One thing I would like to mention about the Unix philosophy in regards to this progect goes back to the command line argument input file containing a previous list of contacts. The rule of composition urges programmers to design programs to be connected with other programs. Even though this aspect of the program ended up causing some issues for peers reviewing and testing the code, it was a really good idea when considering this rule. If a user wanted to use this program, it would be really tedious to manually transfer all contact information from a previous contact book; however, the ability to import this pre-existing information into the program makes it much more appealing. Other programs may not necessarily format the address book data the same way though, and some users may not have an existing address book to import, so this should be taken into consideration for future revisements.