Skip to content
Juliano Lazzarotto edited this page Apr 4, 2024 · 16 revisions

Dev guidelines 🤷‍♂️ + reviewing 👓

What you should consider when reviewing and coding:

  • How declarative is it? (Always prioritize readability)
  • Avoid mutations (favour ISA)
  • Avoid index accessing (prefer deconstruction)
  • Prefer shorthand notations
  • Is it properly typed or overtyped? (type based on client, not on dev)
  • Pay attention to null/undefined when checking (specially numbers + empty strings)
  • Prefer ?? for defaulting
  • Components should represent its intention (a Button should have an onPress prop, don't break known APIs)
  • DRY (remarks here, not always if over-eng to DRY, prefer readability)
  • Avoid margins (they are evil) (we won't approve the PR at all)
  • Optimize only if you can prove that is slow, or justify (a lot) the why
  • Avoid typeof prefer schemas and type guards
  • Import react import * as React from 'react' and to identify React hooks -> I.e React.useCallback (typescript suggestion)
  • Avoid leaking implementation (don't leak the motor under the hood) expose a client design API the implementation is irrelevant
  • Group up same logic
  • Branch logic as soon as you can
  • Prefer => over function() (2 rare cases when you shouldn't)
  • Don’t use React.useEffect as part of the logic
  • Don’t use try catch as part of the logic (errors should crash the app, exceptions should be handled and the app should respond)
  • Pay attention to the commit lint rules
  • Add tests (dahhh)
  • Think about your changes as a FSM (this will make others understand it clearly)
  • Don't be "clever", make it simple KISS (in short words don't over engineer simple things)
  • Add stories and cover all states specially the asynchronous ones
  • Pay attention to don't create a new user or a new use case for dev only
  • The smaller your PR is, the faster it will get merged (so it's your choice to breakdown your changes)