Usage

• The README contained everything I needed to easily use the program:

• The program compiles/runs without errors:

• The program worked as advertised:

Style

• The code is cleaning divided into modules and multiple files:

• Variable and function names are meaningful:

• Comments are used where appropriate:

  while the function names are self-explanatory, docstrings would be useful to provide information about input/output arguments for each function

Philosophy

• The program most closely follows the ed-like interface pattern:

  it would make sense to read text from standard input if some was provided, else go into interactive mode (e.g. like bc)

• This choice of pattern is a good one for this application:

  based on my understanding of the purpose, I think a cat-like filter pattern would be more useful here. What is gained by the interactivity?

• This program follows the Rule of Silence and Least Surprise:

  Given the implementation as a ed-like game the level of output makes sense.

• This program follows the Rules of Modularity and Composition:

  Again, given the implementation as a game, but for what it does it would make sense to want to use in a pipeline, as is it wouldn't work very well interfacing with other programs.

• This program follows the Rules of Representation and Simplicity:

  The three text files are hardcoded into the code. This increases complexity since if a user wanted to analyze their own file they would need to modify the code. A better solution would be to read a list of text files from the current directory and generate a menu dynamically.