Code Review Guidelines for Humans

Code Review - roadmap.sh

Code Review Process: Best Practices

Code Review Checklist - To Perform Effective Code Reviews

10 Simple Code Review Tips for Effective Code Reviews

Design Patterns and Refactoring

MY CHECKLIST:

• Commit Message + Ticket → Check if the commit message is meaningful and if the ticket is present (when needed)

• Fix Version + Target Branch → Check if the branch target is right, accordingly to the expected Fix Version

• Context of the Changes -> Check if the changes are consistent with the ticket’s context

• Strict changes in Bugs/Hotfixes → Check if changes for bugfixes and MAINLY hotfixes are strict and small (atomic when possible), only fixing the bug and nothing more (preventing adding regression issues)

• Giant PRs → It’s a red flag, since due to be hard to review, it can pass with bugs or vulnerabilities (or gets bypassed with an “lgtm” message). Recommendation: PRs with more than 40 file changes, split into multiple PRs (thanks @Eduardo Sabido for this one)

• Well Written Code

  • Syntax → Check if the Syntax is OK to prevent Exceptions/Errors

  • Code Style → Check if it contains all code standards expected/defined by the team

    JavaScript Standard Style

    Javascript Standard Styleguide

  • Language Conventions → Check about variable case definition, function syntax, class usage (.. etc) that is defined in language conventions

    JavaScript Style Guide

    Javascript Code Convention

    1. Introduction

    Java Code Convention

• Performance → Check if the resource used is compatible with the performance required

• Browser Compatibility → Ex. ES6 into JS Code == IE11 Incompatibility

• Clean Code / KISS Concept → Avoid messy and unnecessarily complex code

• Simplification / Readability → Check if it is possible to simplify some logics, like if statements (adding to a variable, for example)

• Pure Functions → Check if the function IS or CAN BE a pure function

• Immutability Concept → Check if an object/variable is getting changed when it shouldn't

• YAGNI → You ain’t gonna need it → Check unnecessary complexity or over-engineering

• DRY → Don't Repeat Yourself

• KISS → Keep it simple (and | ,) stupid

• SOLID

  • Single responsibility principle
  • Open/closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle

  The S.O.L.I.D Principles in Pictures