LogoLogo
  • 👋Cal.com Handbook
  • The Company
    • ❓What is Cal.com?
    • 📈Mission, Vision and Values
    • 🅰️Glossary
    • 📈Organization Chart
  • HR & Careers
    • 👷Contract-to-hire trials
    • 🛫Onboarding
    • 🏆IC Levels
      • ⛰️Engineering Levels
        • 🕵️IC1 Engineer (Code Cadet)
        • 👷‍♀️IC2 Engineer (Code Craftsperson)
        • 🧘‍♀️IC3 Engineer (Code Connoisseur)
        • 🧙‍♂️IC4 Engineer (Code Wizard)
    • 💡Sharing your views
    • 💸Bonus & Equity Structure
  • Policies
    • 🏖️Vacations
    • 💳Expenses
    • 🗣️Communications
  • Engineering
    • 🔔Managing Notifications
    • ⭐Valuable Bookmarks
    • 🐛How to report issues
    • 💻How we work on Tickets
    • 🔥What to do during Emergencies
    • ✅PR Reviews
    • ☑️Self-reviews
    • 📚Keeping Docs up-to-date
    • 🌐HTTPS & Subdomains
    • 🎯Best practices
      • Data fetching
      • Avoid Prop Drilling
      • Prefer defaultHandler for simple API handlers
      • Prefer inferred types over explicit ones
      • Prefer early returns
      • Avoid comparing multiple values with `includes`
      • Validate using zod instead of type casting
      • Prefer Composition over Prop Drilling
      • Prefer ternaries over Short Circuiting “&&” for React Components
      • Don't modularize prematurely
      • Only select data you need
      • Disallowing the use of unrestricted Metadata fields
      • E2E Tests Best Practices
    • 💻Codebase
      • 🔓Keeping the lock file in sync
      • 🚫Git Private Submodules
      • 🏎️Monorepo / Turborepo
      • 🌝Deploying to Production
      • ☁️Deployment
      • 💻Debug Desktop App
      • 🚩Enabling/Disabling Features
    • 🔺Resolving failed migration on Vercel Preview
    • 🔦Cal.com Status Page
  • Customer Success
    • 💟Tone
  • Marketing
    • 🎬Media
    • ☝️How to add a new Tip to Sidebar
  • 🤲Sales
    • Operations Stack
Powered by GitBook
On this page

Was this helpful?

  1. Engineering
  2. Best practices

Don't modularize prematurely

The reason why you should not split files if they're not being used in more than one place is because it can lead to unnecessary complexity and maintenance overhead. If a file is only being used in one place, there is no need to split it into multiple files. This can make it harder to navigate and understand the codebase.

On the other hand, splitting functions and components as much as possible can be beneficial. It can help with code organization, reuse, and testability. By breaking down large components into smaller ones, you can create a more modular and flexible codebase. This can make it easier to maintain and evolve the code over time.

Collocating related code in the same file can also improve code organization and readability. If you have related code scattered across multiple files, it can be harder to understand how everything fits together.

In summary, the decision to split files or not should be based on whether it improves code organization, readability, and maintainability. It's okay to split functions and components as much as possible, but don't split files unnecessarily. Collocating related code in the same file can also be helpful.

PreviousPrefer ternaries over Short Circuiting “&&” for React ComponentsNextOnly select data you need

Last updated 2 years ago

Was this helpful?

🎯