In the KIELER project we are conducting regular code reviews of (possibly) all of our sources. To make things easier, we do software assisted reviews in Crucible.

On this page:

Review Scheme

Reviews are scheduled for every thursday. In the weekly KIELER meeting one author and two reviewers are chosen.

The author's job is then to do as follows:

Now it is the reviewers's turn to perform the review:

Review Meeting

The week after, on Thursday, the review meeting takes place. In the Meeting the following exciting things happen

After the Review

After the review it is up to the author to finish any tasks that have been risen

Code Tags

Design Reviews

When classes are ready for a design review, they should be marked with the following tag:

@kieler.design proposed <comment> 

After the design review has been performed, the same tag can be used to mark the reviewed classes by removing the proposed modifier and adapting the comment. The comment should contain the date of the design review (yyyy-mm-dd) and the login names of the attendees.

Code Reviews

All classes have initial code review rating red. The first code review lifts them to yellow, and the second one to green. The following tag marks classes that are ready for the first code review:

@kieler.rating proposed yellow <comment>

After the code review has been performed, the same tag can be used to mark the reviewed classes by removing the proposed modifier and adapting the comment. Similarly, the second code review can be marked using the green modifier. The comment should contain the date of the code review (yyyy-mm-dd), the login names of the attendees, and the ID of the code review in Crucible (such as KI-15).

Review Overview Page

The design and code review tags are processed automatically using a custom doclet during Bamboo builds. The result is displayed in a generated HTML page:

http://rtsys.informatik.uni-kiel.de/~kieler/rating/

Tag Syntax

The complete syntax of the available tags is as follows:

@kieler.design [proposed] yyyy-mm-dd comment
   Marks a class as design-reviewed or to be design-reviewed. For proposed classes, the
   comment should mention the login name of the person proposing the class to be reviewed.
   For reviewed classes, the comment should include the names of the reviewers.

@kieler.rating [proposed] <yellow|green> yyyy-mm-dd comment
   Marks a class as code-reviewed or to be code-reviewed. For proposed classes, the
   comment should mention the login name of the person proposing the class to be reviewed.
   For reviewed classes, the comment should include the names of the reviewers as well as
   the ID of the review in Crucible (for instance "KI-15").

@kieler.ignore comment
   Marks a class as to be ignored in the code rating statistics. The comment should provide
   an explanation of why the class is ignored.

To be compatible with past tags, the doclet is actually quite flexible in terms of what it still accepts. However, it is good practice to follow these recommendations.