top of page

Code Review Checklist – To Perform Effective Code Reviews

I received many requests to create a high-Level template to use when conducting a code review session. So, here it is :)

Has the reviewer, make sure that:

  • Check that the new code does not affect any public interface.

  • Code review is frontal.

  • Is this code should be applied in other versions or instead a patch should be prepared?

  • You understand the scope of the new/modified code.

  • You prepare by reading the relevant design spec or bug description.

  • You take decisions only after you understand the complexity and risks of the changes.

  • If there are issues and comments raised during the review

  • Ensure that new tasks have been created on demand.

  • If the code was rejected, Ensure to review it again afterward.


  • Ensure that the code is maintainable (structured, readable, and well documented).

  • Is the new code efficient (Memory and CPU consumption)?

  • Irrelevant code should be removed or marked as deprecated.

  • Ensure the code is covered in tests (Unit/Integration).


  • If possible, make the new code coverable by logical dump (Application logical status).

  • Validate new/modified application crash conditions (Kill application after DUMP creation).

  • Ensure to add/modify the logging (info, warnings, and errors).

  • Ensure to add enough traces to the new code.


  • Is there sufficient debug print to understand the execution flow?

  • Ensure that the code does not generate too many log entries.

  • Should any of the output data be encrypted?

  • Are all error codes mapped in the DB (If needed)?


  • Ensure that your new code is covered (reached in runtime) by at least a few test cases.

  • Ensure that your code does not break any Module/Function/Component/Procedure existing functionality by running unit tests, integration tests, and on-demand system tests.

  • New Integration tests should cover positive, recovery, boundaries, and negative scenarios.

  • New UNIT tests should cover positive, boundaries, and negative scenarios.

Explicitly for DB code review

  • In any case, that a code review is made to a DB transaction, we must ensure to cover try/catch and rollback.

  • For all DB queries, Ensure you review the execution plan and resource consumption (memory, CPU, and IO).

  • In any case, that a code review is made to a new/changed JOB we must ensure to cover recovery steps.

  • In any case, that a code review made to a new/changed data access to common used data/table, ensure you use the correct lock mechanism.

119 views0 comments
bottom of page