Frontend Review Guidelines
End-to-end frontend code review process and guidelines
👤 Milind Naik📅 Updated: Feb 2, 2026📁 Code Review Guidelines🏷️ frontend🏷️ code-review🏷️ react🏷️ typescript
Complete end-to-end code review process for frontend development, covering developer responsibilities before raising a PR and reviewer expectations during review.
Before creating a PR, frontend developers must self-review their changes to ensure correctness, readability, performance, and long-term maintainability.
| # | Check | What to Verify |
|---|
| 1 | Code readability | Logic is easy to follow and well structured |
| 2 | Naming clarity | Components, hooks, variables, and functions are meaningful |
| 3 | No dead code | Remove unused imports, commented code, console logs |
| 4 | Single responsibility | Components/hooks do one thing only |
| 5 | Reusability | Common logic extracted into utility/helper functions or hooks |
| 6 | Error handling | API failures and edge cases handled |
| 7 | UI states | Loading, error, empty, and success/failure states covered |
| 8 | Type safety | Types should be clear, consistent, and appropriate for the use case |
- Use TypeScript strictly
- Avoid
any,JsonObject unless explicitly justified
- Follow camelCase for variables/functions
- Use PascalCase for components
- Avoid deeply nested conditionals and JSX
- Prefer early returns over complex branching
- Keep files focused; split large components
- Prefer functional components
- Keep components small and focused
- Avoid unnecessary or duplicate
useEffect hooks
- Ensure
useEffect dependency arrays are correct
- Memoization (
useMemo, useCallback) only when required
- Avoid deeply nested JSX; extract subcomponents when needed
- Use key attribute when rendering lists
- Prefer local state over global state
- Avoid duplicated or derived state
- Keep reducers pure and predictable
- Do not perform heavy transformations inside JSX
| Area | Expectations |
|---|
| Rendering | Avoid unnecessary re-renders |
| Lists | Always use stable keys (avoid index where data changes) |
| Expensive logic | Memoize when justified |
| API calls | No duplicate or parallel calls without reason |
| UX feedback | Loaders, disabled states, or skeletons provided |
- Avoid exposing secrets, tokens, or sensitive internal identifiers in the UI where possible
- Perform basic validation of user inputs before submitting requests (required fields, format checks)
- Do not rely solely on backend responses for simple input correctness or user feedback
- Be cautious when rendering dynamic or user-provided content
| Check | Expectation |
|---|
| ✅ Clear naming | No vague or misleading names |
| ✅ Readable JSX | JSX not deeply nested or cluttered |
| ✅ Clean code | No unused imports or variables |
| ✅ Proper typing | Types are meaningful and correct |
| ✅ Formatting | Matches project conventions |
| ✅ No debug artifacts | No console.log or debugger statements. console.warn / console.error allowed only for intentional, meaningful logging (e.g. third-party integrations or complex API flows). |
| Check | Expectation |
|---|
| ✅ Component responsibility | Components are not overloaded |
| ✅ Separation of concerns | UI, logic, and data clearly separated |
| ✅ Folder structure | Files placed in correct domains |
| ✅ API abstraction | No API calls directly inside JSX |
| Check | Expectation |
|---|
| ✅ Re-render control | Props/state usage reviewed |
| ✅ Memoization | Used only where beneficial |
| ✅ List efficiency | Stable keys and optimized rendering |
| ✅ Effects correctness | No missing or excessive dependencies |
| Check | Expectation |
|---|
| ✅ Loading states | Clear feedback during async actions |
| ✅ Error states | Helpful and actionable messages |
| ✅ Empty states | Graceful handling of no data |
| ✅ Visual consistency | Matches existing UI/design system |
| Check | Expectation |
|---|
| ✅ No secrets exposed | Tokens, keys, internal data hidden |
| ✅ Input safety | Inputs handled defensively |
| ✅ Auth boundaries | Frontend does not bypass auth |