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:

  enterShips would be more modular if it accpted a list of ship sizes and names to enter as an argument. Asking for user names and prompting the user could be moved into a module so the same functions could be called for each of the two users.

• Variable and function names are meaningful:

• Comments are used where appropriate:

  while the code is easy to follow without comments, docstrings would be useful for generating documentation makeing it easier for others to build upon this base.

Philosophy

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

  it would be convenient to accept placement commands on standard input for scriptable startup scenarios.

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

  Since the interface is primarily a graphical representation rather than command/response, a rogue-like interface might me more appropriate.

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

• This program follows the Rules of Modularity and Composition:

  A cleaner separation of game mechanics and interface, possibly implemented with a core engine that made use of standard input to read commands, would allow multiple UI wrappers to be used, allowing a text-based interface like the one provided, or a graphical interface not yet created.

• This program follows the Rules of Representation and Simplicity:

  Board size and ship lists would be best stored in separate files and loaded upon start up. This would give the user flexibility in creating different games without having to modify the code.

Bugs

When player names contain spaces, funny things happen.