AM4 Code Review

Overview

One of the course learning goals is: critique code from your peers or other external sources using technical language that indicates your understanding of topics and issues. This goal is tied to one of the assessment criteria (Code Reviews) of the course, and in this second part of the semester, we will perform three such code reviews.

Our reviews will focus on the two aspects of programming: functionality and style. Code might be doing all what is required, but in a convoluted or redundant way. Usually, efforts for clarity (better style) will also improve the functionality of the code (by using modularity and refactoring).

Functionality

The code functionality is divided in three parts.

You can try the features live on the system, and also look at the printed code.

Calendar Functionality

• App is able to access the user calendar (this code was given)
• Courses are added in the current week.
• All meeting times of a course are added as separate events.
• A dedicated calendar was created once and reused for every occasion (so that they aren't many instances of your calendar)
• One can add many courses at once, as opposed to one by one.
• A notification is generated when all courses are added to the calendar.
• Optional: There is a way to delete the calendar from the app interface

UI functionality

• Three different search criterias were implemented
• Each search criteria works correctly individually
• At least one combination of two search criteria is possible and gives the correct result
• Results are refreshed every time a change is made or with a button click
• There is a way to see that the number of results is changing, whenever a change is made (by showing the total number of found items)
• Buttons for the calendar don't show all at once.
• Is able to indicate that no courses were chosen if someone asks to add them to the calendar.

Data

• What additional data structures were created (besides cleanedCourses)?
• How is the intersection of two different selections implemented? [This might have been part of the UI, but it is set up by the data organization]
• Where courses divided by days, how?
• What additional fields were added to a clean course to make it easier for other data structures to work properly?
• Were any regular expressions used and how?

Coding Style

In addition of the app working, we also should care about the coding style, so that we can maintain and reuse the code in the future. Here are some criteria to consider: (modification of Scott's Anderson Coding Style)

1. Function and variable names should be descriptive.
2. Functions should be focused in doing one thing.
3. Code must be properly indented to show the syntactic structure of the program.
4. Files should have top-level comments about author, purpose, modification history, etc.
5. Each function should be preceded by a brief paragraph explaining what it does, how it works (if necessary) and the meaning of its arguments and return values.
6. Document variables and data structures by explaining their purpose and use.
7. Document any code that is not obvious.
8. Remember that screens and printers have finite width. Stick to an 80-character line.

Modularity

Avoid redundancy and code repetition by looking for suitable opportunities for abstraction via functions.

Groups based on code

Reviewing Process

In Class

You will divide in groups based the same task (e.g. data, or UI, or calendar). In class you will discuss the functionality criteria of the code you wrote.

During the functionality discussion in your group take notes about how other students implemented certain features. Is their version easier to understand? Did they implement parts that you didn't? How does your code compare to theirs in terms of clarity?

Swap your printed copy with someone in the group. You'll use that to provide feedback on the coding style. If someone in the group is missing class today, arrange to meet with them after class to get a copy of their code.

Outside Class

Using the Coding Style criteria, go over the code of your peer, writing notes on the side, or in a separate sheet (you can also type it if you want).

What to submit

On Tue, April 7 bring in class the copy of your peer coding style review to hand out.

On Wed, April 8 by the end of the day, submit a two-part report that contains:

1. Your reflection on the functionality discussion you had in class and what you learned from looking at your peer's code.
2. A summary of the feedback you got about your coding style and what changes you plan to make to your style in the future.

You should send the report by email to Eni. The completion of this report counts for the "Personal Blog, Collaboration and Contribution, Code Reviews [25%]" assessment category. Each code review is worth 2%.

Revision

Some teams after this review process might wish to make changes to their code to reflect the feedback or to add missing functionalities.

You should feel free to do that, provided you don't change the original code and create a new folder titled am4revised. Then, you can link to that revision in your own portfolio. This is a significant coding achievement, the kind of project that you want to show to others, thus, it makes sense to have a bug-free version to share with the world.

Opportunity for contribution credit

One of the opportunities to get credit in this class (especially if you haven't been engaging much in blogging or missed more than one AMs) is contribution. The following is lifted from the Course Info page.

... you can create learning materials such as transcribing class discussions, creating screencasts for doing certain things, or write simple tutorials of using APIs or some interesting Javascript libraries.

Given that AM4 is an application that is useful to Wellesley students, you can get credit for doing a user study on the usability of one or more of the systems created by the teams.

You should pair up with someone who has taken CS 220 or CS 320 in order to define a set of criterias for gathering user feedback. Then, you will set up an instrument to collect this feedback (either online or by personally meeting with users), write a report that summarizes all your findings, and give a short presentation in class to share them with everyone.