Skip to content

Code review list

Jelle Bootsma edited this page May 3, 2021 · 6 revisions

Introduction and Rationale

This document’s purpose is to create a simple checklist to verify code quality on a surface level. With this document every member of the SEP project should be able to consistently check code.

Check list

  • Doxygen comments on all public methods. (Javadoc format) (Yes/ No)

  • Adheres to SOLID principles. (Yes/ No, why not)

  • Passes Class level checks on new code (Yes/ No)

  • Proper memory management (Every new memory allocation should be handled by a delete) (Yes/ No, (e.g. Handled by smart pointer))

  • Naming conventions adhered to. (Yes/ No)

  • Code properly ordered, split up and formatted. (Yes/ No)

  • New code covered by unit tests. (Yes/ No)

Class level checks

The thresholds for the metrics we use are either scientifically proven or industry accepted values or, in case of absence of such, result from industry benchmarks.

  1. Module size
    Software Lines of Code, that is, effective lines excluding blank lines and comments. Threshold: SLO**C <  = 400)

  2. Class complexity
    HARD TO CHECK SO WE WILL LEAVE THIS FOR NOW (AT LEAST I DONT KNOW HOW TO CHECK THIS FOR CPP

    We use cyclomatic complexity metrics. Average complexity per class. Threshold: Cyclomatic complexity  < 10) Maximum method complexity within class Threshold: Max Cyclomatic complexity <=20)

  3. Class design (for object-oriented languages)
    Number of methods in the class. Threshold: WMC <  = 20

  4. Module design (for non-object-oriented languages)
    Number of functions per module/file. Threshold:  <  = 20

  5. Module internal duplication
    Percentage of duplicated clones (in SLOC) inside a module.

  6. Code commenting
    Percentage of lines of comments (% LOCM). Threshold: LOCM/SLOC * 100% > 15%

Clone this wiki locally