Back to Templates

Development Team Coding Practices

Clear guidelines for maintaining code quality and consistency

Last updated
Code Style & Standards
3 questions

All code must be formatted using our automated tools before commit. Install required extensions now to enable auto-formatting on save.

🔧 Required Setup:

  • ESLint + config
  • Prettier + config
  • EditorConfig

📝 Key Standards:

  • 2 space indentation
  • Single quotes
  • Semicolons required
  • Max line length: 100
  • Trailing commas

💡 Quick Setup:

  1. Copy .prettierrc from team repo
  2. Enable format on save
  3. Run npm run lint to verify

Use clear, descriptive names that explain purpose. Variables should be nouns, functions should be verbs. No abbreviations except for common terms.

✅ Naming Conventions:

  • Variables: camelCase
  • Classes: PascalCase
  • Constants: UPPER_SNAKE_CASE
  • Private fields: _prefixUnderscore

📋 Examples:

// Good
const userData = fetchUserData();
const isActive = true;
function calculateTotal() {}

// Avoid
const data = fetchData();
const flag = true;
function calc() {}

🚫 Never use:

  • Single letter variables (except loops)
  • Ambiguous names (data, info, thing)
  • Hungarian notation

Components should be small, focused, and follow our standard structure. Use functional components with hooks by default.

📁 Component Structure:

// imports ordered by: react, libs, components, hooks, utils
import React from 'react';
import { useQuery } from '@tanstack/react-query';

interface Props {
  // required props first
  userId: string;
  // optional props last
  className?: string;
}

export function UserProfile({ userId, className }: Props) {
  // hooks first
  const { data } = useQuery(...);
  
  // handlers next
  const handleClick = () => {...};
  
  // render helpers last
  const renderItems = () => {...};
  
  return (...);
}

🎯 Guidelines:

  • One component per file
  • Max 250 lines per component
  • Extract complex logic to hooks
  • Use composition over props drilling
Git & Version Control
3 questions

We use trunk-based development with short-lived feature branches. All changes require PR review before merging to main.

🌳 Branch Naming:

  • feature/XX-description
  • fix/XX-description
  • refactor/XX-description

📝 Commit Messages:

type(scope): concise description

- Detailed bullet points
- Breaking changes noted

🔄 Workflow Steps:

  1. Pull latest main
  2. Create feature branch
  3. Commit small, logical chunks
  4. Push & create PR
  5. Address reviews
  6. Squash merge to main

PRs should be focused, well-documented, and easy to review. Keep changes small and related to a single concern.

📋 PR Requirements:

  • Clear title referencing ticket
  • Description of changes
  • Testing notes
  • Screenshots (UI changes)

✅ PR Template:

## Changes
- Added X feature
- Fixed Y bug

## Testing
1. Step-by-step guide
2. Expected results

## Screenshots
[If applicable]

💡 Best Practices:

  • Max 400 lines changed
  • Response to reviews within 24h
  • Update branch before merge

Resolve conflicts locally before pushing updates. Keep main branch clean and deployable at all times.

🔄 Conflict Resolution:

  1. Pull latest main
  2. Merge main into your branch
  3. Resolve conflicts locally
  4. Test thoroughly
  5. Push updates

⚠️ Never force push to:

  • main branch
  • shared feature branches
  • release branches

💡 Prevention Tips:

  • Pull main frequently
  • Communicate on shared files
  • Keep PRs small
Testing Standards
3 questions

All new code requires tests. Coverage minimum is 80%, with critical paths at 100%. Tests must be meaningful, not just for coverage.

✅ Required Tests:

  • Unit tests for utils/hooks
  • Integration tests for features
  • E2E tests for critical flows

📝 Test Structure:

describe('ComponentName', () => {
  it('should handle primary use case', () => {
    // Arrange
    // Act
    // Assert
  });
});

🎯 Coverage Rules:

  • Business logic: 100%
  • UI components: 80%
  • Utils/Helpers: 90%

Test files mirror source structure with .test.ts extension. Group related tests using describe blocks, use clear test names.

📁 Test Organization:

describe('UserProfile', () => {
  describe('with valid data', () => {
    it('displays user info')
    it('shows edit button')
  });

  describe('with errors', () => {
    it('shows error message')
    it('retries on button click')
  });
});

🧪 Naming Convention:

  • Describe: component/feature name
  • It: specific behavior
  • Files: same name as source + .test

Mock external dependencies and network calls. Keep component tests focused on component logic, not implementation details.

🎭 Mocking Guidelines:

  • Mock API calls
  • Mock complex dependencies
  • Mock time-based functions

📋 Mock Examples:

jest.mock('api', () => ({
  fetchUser: jest.fn(),
  updateUser: jest.fn(),
}));

// Test file
beforeEach(() => {
  fetchUser.mockResolvedValue(mockUser);
});

⚠️ Don't Mock:

  • Simple pure functions
  • Component props
  • Basic utilities
Performance & Optimization
1 question

All pages must meet Core Web Vitals thresholds. Run performance checks locally before PR submission.

📊 Performance Targets:

  • FCP: < 1.8s
  • LCP: < 2.5s
  • CLS: < 0.1
  • TTI: < 3.8s

🔍 Check Points:

  1. Development:
  • Bundle size monitoring
  • React DevTools profiler
  • Lighthouse CI
  1. Production:
  • Real User Monitoring
  • Performance budgets
  • Automated alerts
FAQBeeMade with FAQBee