Skip to content

General Principles

Code should be self-explanatory. If a developer (including yourself) revisits the code months later, it should be easy to understand at a glance. Prefer clear, meaningful variable and function names over complex logic.

The DRY (Don’t Repeat Yourself) principle encourages creating reusable components and utilities to avoid duplication and reduce maintenance. However, DRY shouldn’t be followed dogmatically.

Enter AHAAvoid Hasty Abstractions. The idea is simple: don’t abstract too early. Abstraction should bring clear value — improved readability, reduced bugs, or easier maintenance — not come at the cost of over-engineering or hurting code clarity.

Rule of thumb: Don’t abstract unless the pattern repeats at least 3 times. When in doubt, prefer duplication over the wrong abstraction.

Key principles to keep in mind:

  • Optimize for change first — code that’s easy to modify beats premature abstraction
  • Prefer duplication over the wrong abstraction — it’s easier to abstract duplicated code later than to untangle a bad abstraction
  • Keep AHA over DRY — a little repetition is better than a complex, hard-to-understand abstraction

Ensure that each part of the code has a single responsibility and is separated based on its concern (UI vs. logic vs. data fetching). This makes the code modular, easier to test, and simpler to refactor.

Rule of thumb: A component or hook should rarely exceed 100 lines of code in its body.

Keep side effects isolated (e.g., in useEffect) and avoid logic in the render body. This helps maintain a pure and easy-to-follow component render flow.

Before using the useEffect hook, ask yourself: Is this really a side effect? There’s a great article, You Might Not Need an Effect, in the official React docs.

Always handle potential errors gracefully, whether from API calls, state management, or user interaction. Provide feedback to users (e.g., error messages, toast notifications) and never let an error crash the app.