TypeScript in a Team: Code Style, Conventions, and No Chaos

Why "It Works" Isn't Enough for a Team?

Imagine: you open someone else's PR, and there's any everywhere, variables named a, b, c, and everything is formatted as if the code was written by a cat walking on a keyboard. Sound familiar? Working alone, you might survive such code. But in a team, this is a path to conflicts, bugs, and sleepless nights on code reviews.

Today, we'll talk about how to make TypeScript in a team not just a tool, but a reliable foundation. We'll break down code style and conventions that will save your nerves and speed up development. No pedantry, just live examples.

1. Strict Typing: Your First Friend

TypeScript is about types. But many teams use it as "TypeScript-lite," leaving any everywhere they're too lazy to think. This kills all the magic. The first convention: ban any.

Bad:

function fetchData(url: string): any {    // ...}

Good:

interface ApiResponse {    id: number;    name: string;    isActive: boolean;}

function fetchData(url: string): Promise<ApiResponse> {    // ...}

When every developer explicitly describes what they return and accept, the code becomes self-documenting. You no longer wonder: "Is this data a string or an object?" Types speak for themselves.

2. ESLint + Prettier: A Non-Negotiable Setup

If your team still doesn't have a unified linter and formatter, stop and set them up right now. ESLint catches logical errors and code style violations, while Prettier makes the code uniform.

Basic ESLint Configuration for TypeScript:

{  "parser": "@typescript-eslint/parser",  "plugins": ["@typescript-eslint"],  "extends": [    "eslint:recommended",    "plugin:@typescript-eslint/recommended",    "prettier" // обязательно в конце  ],  "rules": {    "@typescript-eslint/no-explicit-any": "error",    "@typescript-eslint/explicit-function-return-type": "warn",    "no-console": "warn"  }}

Add Prettier with simple rules: tabs instead of spaces (or vice versa, but consistently), single quotes, semicolons at the end. And enable formatOnSave in your IDE. This will save you from endless arguments about indentation.

3. Naming: Speak the Same Language

Naming conventions are like traffic rules. Without them, there's chaos. In TypeScript, these conventions are common:

• camelCase for variables, functions, methods: getUserData(), userName
• PascalCase for classes, interfaces, types: UserProfile, ApiResponse
• UPPER_SNAKE_CASE for constants known at compile time: MAX_RETRY_COUNT, DEFAULT_TIMEOUT
• I prefix for interfaces — controversial, but many teams use it: IUser. Decide this at the start.

Example of bad naming:

const data = { n: 'Alex', a: 30 }; // what are n and a?

Good:

const userProfile = { name: 'Alex', age: 30 };

4. Project Structure: Don't Hide Everything in One File

When a project grows, the lack of structure is the main enemy. Agree on folders in advance. Here's a popular option for a TypeScript project:

• src/ — source code
• src/components/ — UI components (if React)
• src/utils/ — utility functions
• src/types/ — global types and interfaces
• src/services/ — API work
• src/hooks/ — custom hooks (if React)
\