Dev & Reviewing Guidelines

Our coding and reviewing guidelines

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)