Usage

The instructions provided by the README were clear and straightforward, and the process of running the game was appreciably simple. After cloning I just had to run

$ make
$ ./deal

and everything was up and running. The output to the terminal was well-formatted, though it would have been nice ifthe screen was cleared after each choice rather than continuing down the page; this may just be personal preference, but it felt a little cluttered due to that design for me. The game was definitely responsive as I played and updated appropriately as new values were taken off the board. I think it would be a little better as a game if selecting the ‘help’ option described the controls rather than prompting you to visit the homepage. Additionally, when it prompted me to press ‘y’ to start a new game after I had finished, doing so just caused it to repeat the results and the prompt instead of restarting. Pressing ‘n’ exited as it should have, though. Overall, the usage was definitely commendable.

Style

Running through the (single) source file, I would say that the coding style is definitely good. The program is separated into plenty of functions, each with a description that helped me follow through without getting lost. I was able to understand the general purpose of each one based on its name and output. The organization was certainly acceptable, with proper indentation and spacing, and the names of the functions were consistent by generally starting with a lower-case verb followed by its capitalized object. Variables are also named appropriately and avoid being irrelevant or confusing as to their purpose. The finite-state machine structure in the main function, using the switch statement to encompass the game, is the method I would have used as well.

Philosophy

The program clearly follows much of the Unix philosophy we have been exposed to throughout the semester.

• It accepts input from my keyboard and outputs necessary information directly to the terminal. The interface is straightforward and appropriate for the game type. Since it is meant to be an interactive game, there is no need to be capable of running in a non-interactive mode.
• It compiles and creates the executable file silently, pushing out no unnecessary information to standard output if things go the way they’re supposed to. Additionally, when you input an invalid string mid-game, it indicates as such concisely. Therefore the Rule of Silence is kept to.
• It certainly follows the rules of modularity and transparency, splitting the various processes into cleanly defined functions that act with some degree of independence from one another. It definitely looks to me like it would be relatively easy to debug or add extra code to by amending one function and not having to adjust any material elsewhere.
• It outputs very similar text each round as new cases are picked, and it follows the rule of generation by giving this job to certain functions that can run the algorithms over and over without stuffing the source file with redundant code.

In Conclusion…

Your team did a very good job with this! Any fan of the show would immediately recognize the format and be able to follow along without missing a beat. It was easy to compile and run, and it was created with appreciable style and adherence to programming philosophy.