Code Review Patterns

Sub Topics

• CI/CD 
• Comments
• Semantics 
• Javascript
• React
• Tests or Story

CI/CD

• Your code should pass the pipeline / CI job
• Conditions
  • Lint (JS + CSS)
  • Typecheck (if Typescript)
  • Buildable or not
• For both reviewees and reviewers: Be sure about passing pipeline 

Extra Step

• Review your own code, before present your peers!

Comments

• Absense of comment when needed
• Meaningful, descriptive content
• Bad example: "will be added later"
• Good example: "Add type definitions after service implemationtion"

Semantics

• Commit messages, branch names
• Typo
• Good naming
  • start with verbs for functions
  • descriptive or too generic
• Just for reasoning, if you don't understand the code

Javascript

• Implicit return when its possible
• Use functional alternatives for array operations
  • For both mutation safety and declarative readability
  • using map, reduce, filter over loop and array.push
• unused variables (can be catched by linter, too)
• import grouping (team decision)
• new package addition: necessity?
• can be converted for generic use
• magic numbers and strings
• object/array destructuring

React

• Potential unnecessary render
• Deprecated method usage
• Adding more props or separating to different component
• missing key prop
• move non-related parts (no relation with state and props) out of component
• default prop selection
• unnecessary fragment

Test / Story

• Is it necessary scenario to display or test?
• needs mock data?
• all potential edge cases are covered?

besides the list, anything can be added with respect to your team's consensus