## Peer Reviews

One of the options for obtaining activity points is writing peer
reviews. The goal of this activity is to practice reading and
evaluating code written by others. However, you can only write
reviews for exercises that you have successfully completed yourself.

For example: if you submit 4 practice exercises in week 2, of which
3 pass verity tests (let's say ‹p1›, ‹p2› and ‹p5›), in week 3, you
are assigned a single solution of each of these 3 exercises (i.e.
you will be writing one review for each of ‹02/p1›, ‹02/p2› and
‹02/p5›). The deadline for writing reviews for exercises from the
second week are the same as the deadline for submitting practice
exercises from the third week (Saturday midnight).

Writing those reviews is optional. For each review written, you will
get one activity point, counted in the week in which you wrote the
review (in the above example, that's the third week of the semester,
i.e. they share the ‘slot’ with the ‹02/r› exercise series).

You will only get the points for review if your review has useful
content – it is «not enough» to write ‘I have nothing to say’ or
‘everything fine’ or ‘nothing to comment here’. If the solution is
good, explain «why» it is good (see also below). The reviews that
you submit will be read by your seminar tutor and some of them may
be discussed (the next week) in the class, in the same spirit as the
original solutions themselves.

NB: In any given week, it is only possible to obtain «3 points» for
activity, regardless of «how» you get them (reviews, solving an
‹r›-type exercise in the class, midterm test, and so on). If you get
to review more than 3 exercises, you can pick which ones to do, but
you can still only get 3 points.

### How to Write Reviews

How to fetch the code to review and how to submit the finished
reviews is detailed in Chapter T. Write your comments directly into
the files you are reviewing. Make your comments brief but useful –
your main goal is to help the recipient to improve their programming
skills.

Try to apply the criteria from Chapter Z (ideally refer to the
specific guidelines, e.g. ‘this variable could use a better name,
see guideline 2.b’). Do not hesitate to point out good code (again,
you can refer to the guidelines here, especially if you consider
part of the code a particularly good example of one) or note that
you have learned something while reading the code.

Always insert comments «before» the block you are commenting and try
to stick with the following style (using ‹**› helps readers to
tell apart review comments from original author's comments):

    /** A short, one-line remark. **/

For multi-line comments:

    /** A longer comment, which should be wrapped to 80 columns or
     ** less, and where each line should start with the ** marker.
     ** It is okay to end the comment on the last line of text like
     ** this. **/

Do not change any existing lines (specifically make sure that any
automatic reformatting of code your editor might do is disabled).
The only permissible operations are:

 • insertion of new lines (empty or with a comment), or
 • adding a comment to an existing «empty» line.
