Why Code Walks?

A code walk is a presentation where you, the programmer, present and defend your code to a review panel (in this case, the professor and perhaps a TA). Code walks are valuable for two reasons:

• they allow you to sharpen your software construction skills, as code reviews are standard practice at many companies.
• they provide personalized critiques of your work to an extent that we could not achieve through merely reading or running your code.

During a code walk, programmers describe their code and why they implemented it as they did (why they used certain data structures, coding formats, and test cases, for example). The review panel asks questions to determine whether the code is well-structured, correct, efficient, robust in the light of possible errors, and extensible, to name a few criteria. As the programmers answer the questions, the review panel can assess the quality of the code and how carefully the programmers thought about its design and implementation.

When and Where?

Logistics

• A code walk is a formal presentation (don't dress up for this though! Only your presentation should be formal). Prepare transparencies containing your design, code, and test cases (we will provide the overhead projector; we will NOT have a laptop projector). You may organize these transparencies as you see fit (ie, they do not have to contain the code in the same order as in your files). Make sure the transparencies look reasonable (no ends of lines missing, break long code into several slides if necessary, etc). Don't break functions across transparencies, as this will make it harder for us to read your code.

• At the code walk, you will present your transparencies, describing the design/code/tests on each one (what it does, why you designed it the way that you did, etc). The panel will periodically interrupt you and ask you questions about your work or ask you to skip to the next function. Be flexible in your presentation so that you can move around parts of the design and code as necessary.

• Ideally, your entire group should attend the code review. If this is not possible due to scheduling constraints, the group members who are there must be able to defend all of the work, regardless of which group member(s) actually did it.

• Missed code walks may not be rescheduled.

• The code and design that you present must be the same code that you turned in for the project. Do not alter the code's behavior in any way from what you turned in.