TypeScript em equipe: code style, convenções e nada de caos

Treinador Online de Python para Iniciantes

Aprenda Python facilmente sem sobrecarga teórica. Resolva tarefas práticas com verificação automática e escreva código diretamente no navegador.

Start Course

Por que "funciona" não é sobre equipe?

Imagine: você abre um PR de outra pessoa e lá tem any em cada esquina, variáveis nomeadas a, b, c, e tudo formatado como se o código tivesse sido escrito por um gato andando no teclado. Familiar? Sozinho, esse código até dá para aguentar. Mas em equipe, isso é caminho para conflitos, bugs e noites sem dormir em code reviews.

Hoje vamos falar sobre como fazer do TypeScript em equipe não apenas uma ferramenta, mas uma base sólida. Vamos abordar code style e convenções que vão salvar seus nervos e acelerar o desenvolvimento. Sem chatice, com exemplos práticos.

1. Tipagem estrita: sua primeira amiga

TypeScript é sobre tipos. Mas muitas equipes o usam como "TypeScript-lite", deixando any em todos os lugares onde têm preguiça de pensar. Isso mata toda a magia. A primeira convenção: proibir any.

Ruim:

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

Bom:

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

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

Quando cada desenvolvedor descreve explicitamente o que retorna e recebe, o código se torna autodocumentável. Você não fica mais adivinhando: "Esse data é string ou objeto?". Os tipos falam por si.

2. ESLint + Prettier: configuração que não se discute

Se sua equipe ainda não tem um linter e formatador unificados, pare e configure-os agora. ESLint captura erros lógicos e violações de code style, enquanto Prettier torna o código uniforme.

Configuração básica do ESLint para TypeScript:

{  "parser": "@typescript-eslint/parser",  "plugins": ["@typescript-eslint"],  "extends": [    "eslint:recommended",    "plugin:@typescript-eslint/recommended",    "prettier" // obrigatório no final  ],  "rules": {    "@typescript-eslint/no-explicit-any": "error",    "@typescript-eslint/explicit-function-return-type": "warn",    "no-console": "warn"  }}

Adicione o Prettier com regras simples: tabs em vez de espaços (ou vice-versa, mas de forma uniforme), aspas simples, ponto e vírgula no final. E ative formatOnSave na IDE. Isso vai evitar discussões infinitas sobre indentação.

3. Nomenclatura: falem a mesma língua

Convenções de nomenclatura são como regras de trânsito. Sem elas, é caos. No TypeScript, adotam-se estas convenções:

camelCase para variáveis, funções, métodos: getUserData(), userName
PascalCase para classes, interfaces, tipos: UserProfile, ApiResponse
UPPER_SNAKE_CASE para constantes conhecidas em tempo de compilação: MAX_RETRY_COUNT, DEFAULT_TIMEOUT
Prefixo I para interfaces — é controverso, mas muitas equipes o usam: IUser. Decidam isso no início.

Exemplo de nomenclatura ruim:

const data = { n: 'Alex', a: 30 }; // o que são n e a?

Bom:

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

4. Estrutura do projeto: não esconda tudo em um único arquivo

Quando o projeto cresce, a falta de estrutura é o maior inimigo. Combinem as pastas com antecedência. Aqui está uma opção popular para projetos TypeScript: