Is this still useful in the age of AI-generated code (Feb 2026)? Yes. Readability matters whether code is written by humans or LLMs, someone still has to review, debug, and extend it. That may change in the future, but not today.

This guide is my roadmap to consistency, readability, and maintainability.

Remember

• Code is for humans, not machines.

  Write code that is primarily understandable and maintainable by others. Writing code that others can read, understand, and maintain is a form of professional respect. Code, at its core, is communication.

• Working code ≠ good code.

  You are an author. Write your code so that it can be read. Accept criticism that may seem trivial, such as renaming a variable or method. If someone suggests a rename, it means the original name didn't communicate its purpose clearly enough.

React Style Guide

Component source file structure

Component files consist of the following, in order:

1. Import statements
2. Main component implementation
   1. Main component props (optional)
   2. Main component declaration
3. Helper components (optional)
   1. Helper component props (optional)
   2. Helper component declaration
4. React hooks (optional)
   1. React hook signature (optional)
   2. React hook declaration
5. Other helper functions (optional)

The most important thing in a file is what you export — the public API. That goes first. All the helpers and utilities are implementation details; they come second.

Export named components; do not use default exports

As stated in the TypeScript Style Guide, always use named exports.

Unless a default export is specifically required (e.g., page components in Next.js), use named exports.

Always use functional components

Never use class components. They are discouraged by the React team: Component – React. Functional components have a simpler syntax — no lifecycle methods, constructors, or boilerplate.