COSC 3353 Code Reviews
Purpose: After you submit
most programming assignment you will then be asked to do a code review. A
code review allows you to look at another students code and give that student
feedback on their code and the rest of the package. You will be assigned to
accomplish two code reviews for each programming assignment. Code reviews
are standard industry practices. You need to be able to look at other programmers
code and help them improve their programming skills. You should also improve
your programming skills by critically looking at other students code.
Each code review will be graded. Typically there will be at
least two students reviewing each assignment, but there may be more if needed.
I will also be using the code reviews to assist me in grading the original
Some reviews will be fairly short, for example if the code you
are reviewing is well written, appropriately uses the language, is well-documented,
and gives the correct result, your review will typically be under one page.
You may contact the author of the program before you submit
your code review, if you have questions about the code/assignment. You may
not contact the other person who is doing
the review of this program.
Due Date: You
will have one week to complete the code reviews. Your programming assignments
will be due before class on Monday. I will then randomly assign your code
to two other students to accomplish the code reviews, typically sometime Monday
afternoon. They will be due the following Monday before class. That is why
programs submitted late, will not be accepted!
Code Review Requirements: You
are not grading the other students program, instead you are giving constructive
criticism to the other student. Accomplish the following for each code review
- Take the source code from the student and compile/interpret the program.
Document if there are any errors/warnings as part of the compile process.
- Run the program with the authors test data and your own test data.
- Does it give the expected results (remember this authors code may be
correct and your code wrong)? If not, document the discrepancies. You
should also determine where in the code the problem is caused and what
needs to be corrected to resolve the issue. Include this information in
- Does the program meet all the requirements given in the assignment.
If not, document what is missing or incorrect.
- Look at the user interface that the program provides. Is it a well designed
user interface that is easy to use? Does the interface provide the user
an explanation of what the program does and what inputs are needed. Document
any problems you find or suggestions to make the interface better. NOTE:
Some of the programs we will be writing will not have a user interface,
in these cases you will not need to include this part of the assessment.
- Does the program provide additional features beyond the minimum given
in the requirements? Document these features and praise the programmer
for going above and beyond the requirements.
- Review the source code. Document how the code could be improved. Make your
reference to the code via line number. Here are some areas that you might
- Variable Names. Variable names should be descriptive of what the the
variable does and the type of data stored in the variable.
- Initializations. All variables should be initialized or it should be
immediately apparent where the initial value is coming from.
- Variable Scope. Is variable scope used properly? Are global variables
avoided, unless required for a specific application? Is there any confusion
possible in variable names, such as using the same variable names in multiple
locations in such a way that each variables scope is hard to determine?
- Proper Types of Variables Used. Are variable types appropriate? In general
integers are always preferable to real variables, unless the value is
truly floating point. Boolean data should be stored in Boolean variables.
- Arrays. Are arrays used properly, with no overflow? Are dynamic arrays
used if the size of array is unknown at compile time?
- Program Layout. Does the program layout make sense? Are functions/procedures/OOP
used to allow maximum abstraction? Does the program indent properly to
outline what is happening semantically? Is white space used to help the
reader understand what the program is accomplishing? Are there any lines
that exceed 80 characters in length that will make the program difficult
- Use of Functions/Procedures. Are functions/procedures used to avoid
repetitive code? Are variable appropriately passed by reference/value
to functions/procedures? Does the use of functions/procedures allow for
- Language Usage. Is the language usage the program appropriate? For example,
in Scheme, it is possible to do iteration, but normally recursion should
be used instead of iteration. Are the unique features of the language
- Documentation. Is the program well documented? Is there a program identification
section? Does each module/function/procedure have documentation associated
with it, especially variables passes in and out and what are the pre and
post conditions? Is there in-code documentation for all confusing/tricky
sections of the code? A good rule of thumb is that if the review cannot
figure out what is going on in a section of code, then the documentation
is probably insufficient.
- Code Factoring. Is there repetitive code in the program that needs to
be factored into a module or function?
- Struct Design. Are the structs well designed with a logically grouping
of variables? Are there variables that are used independently that should
be groped into a struct?
- Object-Oriented Programming (OOP) Usage. If the language supports OOP,
are the objects used appropriately such that cohesion is maximized and
coupling minimized? Are conglomerate objects used when individual cohesive
objects should be used?
- Memory Management. If the language does not support garbage-collection,
is appropriate deallocation of memory occurring to avoid memory leaks?
Are there any array overflows that could cause memory corruption?
- Review the Submission Package. Does the submitted information meet the program
requirements? Document any missing items.
Submission. Submit your
code review to me via Blackboard and send a copy to the program author via
email. Zip your content if there is more than one file in your code review.
Blackboard only allows a single submission per assignment, therefore if
you have corrections or updates, they must be submitted to me via email.
Reviews should either be written in Microsoft Word or in ASCII text. Your
review should always contain the following:
- The assignment number you are reviewing
- The name of the person whose assignment you are reviewing.
- Your code review in a well layed out format.
Disagreements. If you
disagree with what is stated in the code review, feel free to discuss your
points of concern with the person who did the review. For example, suppose
the person who did your code review felt that your program gave the wrong
results on one or more test cases. Feel free to to work out between the
two of you what the correct answers should be and if necessary, come to
me to resolve the issue. If you both agree the original review is incorrect,
please forward the corrected review to me, otherwise, I will assume the
original review is acceptable to both parties. These corrections must be
completed within one week of when the original review is due or the original
Grading Criteria: 50
points are available for each code review. So the two code reviews you accomplish
has the same weight as the program you originally wrote. Here is how I will
grade the code reviews:
- 25 points for format of the review. Is the review well formatted and
easy to understand? Is proper English and spelling used? Are references
easy to understand (using your code review is it easy to figure out what
is specifically being commented on)?
- 75 points for the technical quality of the review. Some areas I will be
- Were there problems in the program that were not commented upon?
- Were the comments constructive and helpful to the program author?
- Were they easy to understand?
- How much effort was put into the code review?
- Were areas that were well done appropriately recognized?