Peer Code Review Rubric

Variable Names

The variable names describe the intent of the underlying code. Use variable names that describe the source code's intent or purpose. Avoid using variable names that have no meaning, such as those that consist of only one or two letters and have no meaning; avoid using variables that are confusing and unreadable (e.g., abbreviations of a the name stands for / acronym).

1. No variable names meet the criteria;
2. 25% of variable names meet the criteria;
3. 50% of variable names meet the criteria;
4. 75% of variable names meet the criteria;
5. All variable names meet the criteria.

Comments

The header comments of routines and modules summarize the goal of each part of the program and explain parameters (i.e. how to use the part); the spelling Is correct as well. Inline comments in the code help to explain and elaborate on the decision. Comment headers on routines or modules explain each parameter and describe the purpose of each part of the program. In addition, the spelling is correct. Each routine or module should have a comment header that provides a clear and up-to-date description of the routines/modules and their parameters. Comment headers that are redundant or unusable should be avoided. Inline comments provide useful information in some parts of the source code that require explanation. It is recommended that comments be added to some parts of the source code that require explanation, so that people reading the code can understand the flow of code and the reasons for making decisions. Avoid using difficult-to-understand language.

1. No headers and inline comments at all;
2. 25% of the code contains headers and inline comments;
3. Half of the code contains headers and inline comments according to the criteria;
4. 75% of the code contains headers and inline comments according to the criteria;
5. All code contains headers and inline comments according to the criteria.

Layout

The layout of the code has been optimized for readability (e.g. grouping code and ordering code). The indentation, blank lines, spacing and brackets (formatting) have been used consistently to highlight the intended structure of the code formatting. The layout of the source code, for example, code grouping and code positioning, is optimized to make the source code easier to read. Consistent positioning, such as variable declarations at the top, frequently accessed routines at the top, and other related routines close together. The formatting of the source code structure is done consistently. For example, indentation/tab key use blank lines/code blank lines, spacing/spaces, and brackets/ OP. Furthermore, the length of each line of code should be kept to a minimum.

1. The layout and formatting do not meet the requirements;
2. 25% of code employs layout and formatting according to the criteria.
3. half of the code makes use of layout and formatting according to the criteria.
4. Appropriate layout and formatting are used in 75% of the code. criteria;
5. All code follows the criteria for layout and formatting.

Expressions

The codes make use of simple expressions and data types. The source code employs simple expressions (equations/formulas) and the appropriate data types.

1. Some data types are inappropriate or the expressions are difficult to read/understand;
2. All data types are appropriate and the expressions are simple to read/understand.

Control Flow

The control flow of the code is simple and limiting exception. Moreover, the chosen control structure and libraries are appropriate. The control flow and flow of a source code is simple, which reduces the occurrence of exceptions. Control structures and libraries are chosen as needed. Deep nesting and perplexing control structures should be avoided.

1. Control flow produces unexpected output, no exception handling at all;
2. Control flow produces less than expected output, no exception handling at all;
3. Control flow produces output that meets expectations, but uses a less simple control flow, exceptions are not handled properly;
4. Control flow produces output as expected, is simple, exceptions are not handled properly;
5. Control flow produces expected output, is simple, and exceptions are handled well.

Decomposition

A decomposition that results In most routines having a limited set of tasks and removing duplication. Routines should be divided Into parts for different tasks. Furthermore, a decomposition has a limited number of shared variables. Having a well-defined modularization subject. Decomposition results in a program routine with a finite set of tasks and no duplication. Different tasks are divided into sections within a program routine. Furthermore, decomposition has a limited number of shared variables.

1. There is no module division at all;
2. There is a module division, but the tasks on the module are not specific;
3. There is a module division with a fairly specific division of tasks, but there is still a lot of redundancy;
4. Dividing into modules with a specific task division, but not optimal;
5. Dividing into modules that serve a specific purpose.

Table Layout

📚 References