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
- Save the contents of the email to a file.
- 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.
- To decode the uuencoded file, type the command:
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
- To uncompress the compressed file, type the command:
This will produce a file with the name xxxx. This file is tarred.
- 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.
An example of the this information is as follows:
- The number of the machine problem you are critiqueing.
- The name of the student whose code you are critiqueing.
- The user ID of the student whose code you are critiqueing.
- Your name.
- Your user ID.
Critique of MP 1 for Hong Cao, email@example.com
Written by Amit Bhadoria, firstname.lastname@example.org
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?
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.
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
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.
- 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.