Usage

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

• The program compiles/runs without errors:

• The program worked as advertised:

  slight differences in encrypted, decrypted files. Try encrypting README.md, then decrypting to a new file and running diff on both. I would expect them to be identical but one has a trailing newline at the end of the file and one does not. This is probably not a big deal if we are only ever dealing with text files.

Style

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

• Variable and function names are meaningful:

• Comments are used where appropriate:

  description of input/output arguments for functions would be helpful

Philosophy

• The program most closely follows the filter,compiler interface pattern:

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

  this seemed to be a bit of a cross between the compiler pattern (input/output files specified with command line options) and the filter pattern. I think it would make since to follow a cat-like pattern, allow the user to specify an arbitrary number of files as CLAs and encrypt/decrypt all of them to the output stream.

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

• This program follows the Rules of Modularity and Composition:

  I'm inclined to think more flexibility would be gained if the (en

  de)cryption functions were moved into a separate module, currently both the user interface (GetPassword, etc.) and algorithm lives in the same module. At least in the current implementation, this doesn't inhibit the program working well in a pipeline though.

• This program follows the Rules of Representation and Simplicity:

  since the password can be supplied as a CLA encryption/decryption can be fully scriptable, good! There are some magic numbers in the code, settings for the (en

  de)cryption algorithms. It would be best if these were supplied in a configuration file.