Need Project or Assignment
Code Walkthrough?

Get line by line explanation of code by code mentor

Are you struggling with understanding the code?


new to coding journey

We offer online tutoring, online programming session, Coding help at affordable price and line by line code explanation for your programming project, assignment, homework and coursework

What is Code Walkthrough?

Code Walkthrough is a form of peer review in which a programmer leads the review process and the other team members ask questions and spot possible errors against development standards and other issues.

  • The meeting is usually led by the author of the document under review and attended by other members of the team.

  • Review sessions may be formal or informal.

  • Before the walkthrough meeting, the preparation by reviewers and then a review report with a list of findings.

  • The scribe, who is not the author, marks the minutes of meeting and note down all the defects/issues so that it can be tracked to closure.

  • The main purpose of walkthrough is to enable learning about the content of the document under review to help team members gain an understanding of the content of the document and also to find defects.

Checklist for Code Walkthroughs

Before the Walkthrough

Collect the package*. This may include:

  • Requirements (what is this code supposed to do?)

  • Design Doc (what is the overall shape? how do the piece fit together?)

  • Protocol Diagrams

  • Expected Usage (scenarios, programming skeletons, sample programs)

  • Code (a line numbered version helps the review!)

  • Reference pointers (if the code uses a special library, coding style, etc., provide pointers to where the participants can find explanations).


Pick the participants. This may include:

  • the developers

  • selected additional technical types

  • (OPTIONAL) additional interested parties (send a public invitation to source-reviewers, saurons, etc. and see who turns up? if so, make it clear that participants are expected to invest up front time and "get with the process")

  • Pick a time

  • Arrange for a room

  • Send out a notice, providing:

  • Pointer to the package

  • time and place

  • Basic agenda

  • Description of the process that is expected

At the Walkthrough

  1. Go over the rules and the process with all participants before you start.

  2. Identify roles: Who is the facilitator? Who is taking notes?

  3. Collect Issues, Don't Solve Them

  4. Don't defend the code or the project--this is NOT the right place to rearchitect, redesign, or just whine.

  5. Do understand the issue. If it isn't clear, ask for definition, explanation, examples.

  6. Do one issue at a time. Until it has been restated clearly and everyone agrees that the statement accurately captures the issue, do not go on to the next issue.

  7. Drop the egos at the door. An issue with the code is NOT an issue with the person who wrote it--as far as possible, consider this code as having been spontaneously generated by 10,000 random monkeys hammering on keys--your job is to find the Shakespearean phrases in the middle and point out the cruft around the edges.

  8. Do notice good as well as bad. If there is a piece of code that is really clear, well-written, etc. -- say so!

After the Walkthrough

  1. Collect all the issues in written form and send it to participants.

  2. Soon, decide what to do with each issue. If needed, hold a follow-up meeting to assign corrective work or decide what to do with each issue.

  3. Publicize what happened with each issue.

  4. Stow a copy of the package and the results in your project notebook.

(Note: the "package" may consist of a page pointing to where materials are, or it may actually be a physical collection of the materials, depending on the project. Especially in current development efforts, I would expect most "packages" to be "virtual" ones, consisting of links or reference pointers to the materials.)


Note: a 2,500 line packet of code is just about the right size for a two hour code review.

Note: Have some of the reviewers read the code in a different order. The code you read first and the code you read last are treated somewhat differently.

Note: If you want to have everyone use the same package, hand it out physically before hand AND/OR provide directions for how to do the line numbering.