Participation

Class Discussions

Students will be expected to actively participate during class and to meaningfully contribute to class discussions. In general, students should volunteer such participation (but may be involuntarily volunteered). As a part of this participation, students will need to attend every class and lab session for the course. Not being present for any graded component of the class yields a score of 0 for that component automatically. Students will be graded not merely on the existence of their contributions to class discussions but also on the quality of said contributions.

In order to make sure the appropriate students get credit for their contributions, every student should make a paper nameplate with their name clearly printed. Students should bring these to class. Contributions by students without nameplates may or may not be counted. Instructions for creating such a nameplate can be found here.

Code Review Wednesdays

One form of participation, both individual and group, will be in class code reviews. Each group will submit 150-200 lines of code from their term project via CourSys by Friday at 10PM each week. I will curate the submissions and make code available to the class. Each student will review the code and submit comments by 10PM Tuesday night. Reviews should include at least 3 points for each code sample discussed. Each point should identify a strength, weakness, or alternative in the code along with a justification of why you have come to such a conclusion. We will then review and discuss the code on Wednesday of each week. Groups will first walk the class through their code (5 minutes) followed by discussion of trade offs made in the code, risks present, and how the code might be improved. Note that I reserve the right to select any code from the term projects (or other sources); however, this gives groups the opportunity to select code that they found thorny or particularly displeasing to write. Note, all reviews may be sent out to the entire class. Keep them honest, but also keep them respectful.

The code that each group submits should compile and run. It does not to be entirely correct for all inputs, but it should be clear that the group has at least tried to execute the code. Design prototypes that provide executable scaffolding for project features are fine.

Code review Wednesdays will start after the first week of labs.

Guidelines for code review

Initially, you may think that the sole purpose of code review is to identify defects. The actual value extends beyond that into [Bacchelli 2013]:

• Overall improvement of code
• Identifying alternative solutions
• Building a sense of shared ownership
• Transfering about what parts of a code base do or of team idioms
• Transparency & team awareness

Our in class reviews span multiple teams and will not cover all of these points; however, focusing on small, syntactic issues is less valuable overall. The 3 points that you identify for each sample should try to focus on:

Design issues

• Is the intent of the code clear?
• Does it have a clear, focused responsibility?
• Is it designed to be hard to misuse? Could confusion cause errors?
• Is the code appropriately idiomatic for the language (C++ in this case)?
• Does the design violate the principle of least astonishment[1]?
• Are there issues with coupling? (temporal, odd inheritance, leaky abstractions)
• How might the code better handle change?
• Are there alternative designs that could provide better trade offs?
• Are there performance or security concerns that should be addressed?

Code construction issues

• Do all names make sense? (types, functions, variables, …)
• Is code needlessly repeated?
• Do comments clarify or just repeat what the code does?
• Is the API appropriately separated from the implementation?
• Are errors handled appropriately?
• Are invariants clearly expressed?
• Are control structures deeply nested?
• Are there broad stylistic issues?

Try to avoid focusing on purely superficial issues. In many cases, such issues can be handled by automated tools, and they are the least beneficial aspects of code review.

Also, remember that code review is an egoless process. Please keep that in mind both while reviewing and while being reviewed.