CS 340 - Code Critiques

Your critique is to be handed in during class and must be typed. Handwritten or electronic copies will not be accepted.

Critique # 1 (for MP 2) Due: 10/24/2006

Critique # 2 (for MP 3) Due: 11/14/2006

The code that you are to critique will be emailed to your from the i340 account (the EECS 340 Instructor Account). The code will be tarred (a Tape ARchive file), compressed and uuencoded. To extract the code perform the following steps.
  1. Save the contents of the email to a file.

  2. Edit the file to remove any extra information at the begginning and end of the file. The email will have two lines that inform you what needs to be removed. One line states "delete this line and above" the other line states "delete this line and below". This will result in a file that is uuencoded, compressed and tarred.

  3. To decode the uuencoded file, type the command:

    uudecode <filename>

    where <filename> is the name of the file that you saved the email to. This command will produce a new file with the name xxxx.Z, where xxxx will be the user ID of the student whose code you will critique. This file is compressed and tarred.

  4. To uncompress the compressed file, type the command:

    uncompress xxxx.Z

    This will produce a file with the name xxxx. This file is tarred.

  5. To extract the files from the tar format, type the command:

    tar -xvf xxxx

    This will extract the tarred files and produce the files that the student submitted using the turnin command.

Your write up must have the following information clearly expressed at the top of your critique. This information is needed to help get the proper information to the correct student.

  1. The number of the machine problem you are critiqueing.
  2. The name of the student whose code you are critiqueing.
  3. The user ID of the student whose code you are critiqueing.
  4. Your name.
  5. Your user ID.
An example of the this information is as follows:
    Critique of MP 1 for Hong Cao, hcao1@cs.uic.edu

    Written by Amit Bhadoria, abhadori@cs.uic.edu

In the above information, Amit Bhadoria wrote the critique and Hong Cao wrote the program. Your name and user ID is to replace those of Amit Bhadoria.

Your critique is to address the following areas. The questions listed are to give you an idea of what types of things you are to look for in your critique.

The Program Write-up
How well does the readme file introduce you to what is going on in the program? Is the program write up understandable (use well written sentences and proper grammatical form)?

The Program Style
How well is the program commented? Does it have a file header comment at the beginning of every file? Does every function have a function header? Does it make good use of in-line comments? Are identifiers given meaning names? Does the program use indentation and blank lines in a uniform manner to help make the program easier to read? Use the Programming Style handout as a base for good programming style.

Data Structures and Algorithms
Do the data structures use memory efficiently? Do the algorithms use machine cycles (time) efficiently? Do the data structures properly model their "real world" entity? How does the data structures and algorithms used compare to the data structures and algorithms used by your program?

Code Structure and Code Features
Are decision statements (if, while, etc.) easy to understand? Does the code make proper use of cohesion and coupling?
  • The best use of cohesion is when each function performs one well defined operation. Are the functions of small enough size to be easily understood (or are there a few huge functions that do everything)?
  • The best use of coupling is when each function does not depend directly on the operations performed by other function. This is reached by maximizing the use of parameters and minimizing the use of global variables.
Does the program make use of modern programming practices? Such items include typedefs, classes, constructors, desctructors (for dynamic deallocation), multiple source code files, makefiles, etc.

Overall Readability
Was the code easy or hard to understand? If you had to make a change to this program, do you think it would be easy or hard to modify?

For each area you are to write comments about your opinion of the code you are to critique. Your are to give supporting comments of your opinion with specific examples from the code you are critiqueing. Simply giving yes/no answers will not be excepted as correctly doing the critique. Also you are to rate each area with a score from 1 to 5. Where 1 means the area was poorly addressed in the program and 5 means the area was addressed very well in the program.