ECE 2524

Introduction to Unix for Engineers

Give a fish, teach to fish

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:

    card definitions seemed to be spread accross both files. Try to keep all data for the same types of things together, everything needed to define a deck of cards should be in cards.py. It would probably be helpful to create a Deck class and a Hand class. Each player would have a Hand which would be a subset of a Deck. Then the checkForSet method would work on an arbitrary hand and the if player logic could be eliminated.

  • Variable and function names are meaningful:

  • Comments are used where appropriate:

    while the code was self explanatory, more docstring comments would allow easy documentation generation.

Philosophy

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

    like other similar games accepting commands on standard input would be nice.

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

    This type of game could benefit nicely with more of a client-server interface. Imagine if there was a server module that accepted an input stream of commands and a client module that sent commands to the server and read a response. A client class that provided a user interface and prompted for user input could be created, as well as an AI client. The a game could be started with any combination of human/AI clients from player vs. player to player vs. AI to a heated match of AI vs. AI.

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

  • This program follows the Rules of Modularity and Composition:

    the deck of cards is coupled with the game, there is no way to create a deck of cards without also removing 7 for the computer player and 7 for the human player.

  • This program follows the Rules of Representation and Simplicity:

    Point values for different cards would be better stored in a data structure, such as a dict. It might even make sense to define this and different types of decks in text files that could be loaded.