Usage

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

  It's not clear from what is provided how to use the game.

• The program compiles/runs without errors:

  worked after I fixed the Makefile and file names.

• The program worked as advertised:

  I think so. It's hard to say, I'm not sure what to expect. It's not clear how the squares are numbered before experimenting, or what is happening when I select numbers. When I enter a letter instead of a number the program enters an infinite loop.

Style

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

• Variable and function names are meaningful:

• Comments are used where appropriate:

  The function names are pretty clear, but docstring style comments with each class and function definition could clearly describe what the input parameters were expected to be and what the output should be.

Philosophy

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

  would be more flexible and consistent to accept commands from standard input.

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

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

  if this is intended to act as a core and interface with a UI as the README suggests then there could be fewer prompts and the board output should be in a more machine-readable format.

• This program follows the Rules of Modularity and Composition:

  if this is just the core, then see comments above. If this is intended to provide a UI around the core then the code doesn't reflect that separation. Many of the API functions had side effects of generating output. This makes a clean separation of game logic and UI difficult to obtain.

• This program follows the Rules of Representation and Simplicity:

  two separate functions for playeroneturn and playertwoturn add unecessary complexity. Both do the same thing, only the data that is acted upon is different.