TypeScript en equipo: code style, convenciones y nada de caos

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

¿Por qué «funciona» no es suficiente para un equipo?

Imagínese: abre un PR de otro y ve any por todas partes, variables llamadas a, b, c, y todo formateado como si el código lo hubiera escrito un gato caminando sobre el teclado. ¿Le suena? En solitario, ese código se puede soportar. Pero en equipo, es el camino a conflictos, errores y noches sin dormir en code review.

Hoy hablaremos de cómo hacer de TypeScript en equipo no solo una herramienta, sino una base sólida. Analizaremos el code style y las convenciones que salvarán sus nervios y acelerarán el desarrollo. Sin ser pesados, con ejemplos prácticos.

1. Tipado estricto: su primer aliado

TypeScript se trata de tipos. Pero muchos equipos lo usan como «TypeScript-lite», dejando any en todas partes donde da pereza pensar. Eso mata toda la magia. Primera convención: prohibir any.

Mal:

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

Bien:

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

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

Cuando cada desarrollador describe explícitamente lo que devuelve y recibe, el código se vuelve autodocumentado. Ya no tiene que adivinar: «Este data ¿es string u objeto?». Los tipos hablan por sí mismos.

2. ESLint + Prettier: una configuración que no se discute

Si en su equipo aún no hay un linter y formateador unificados, deténgase y configúrelos ahora mismo. ESLint detecta errores lógicos y violaciones del code style, mientras que Prettier uniformiza el código.

Configuración básica de ESLint para TypeScript:

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

Añada Prettier con reglas simples: tabs en lugar de espacios (o viceversa, pero uniforme), comillas simples, punto y coma al final. Y active formatOnSave en el IDE. Esto evitará discusiones interminables sobre sangrías.

3. Nomenclatura: hable el mismo idioma

Las convenciones de nomenclatura son como las reglas de tránsito. Sin ellas, hay caos. En TypeScript se usan estas convenciones:

camelCase para variables, funciones, métodos: getUserData(), userName
PascalCase para clases, interfaces, tipos: UserProfile, ApiResponse
UPPER_SNAKE_CASE para constantes conocidas en tiempo de compilación: MAX_RETRY_COUNT, DEFAULT_TIMEOUT
Prefijo I para interfaces — es discutible, pero muchos equipos lo usan: IUser. Decídanlo al inicio.

Ejemplo de mal naming:

const data = { n: 'Alex', a: 30 }; // ¿qué son n y a?

Bien:

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

4. Estructura del proyecto: no esconda todo en un solo archivo

Cuando el proyecto crece, la falta de estructura es el peor enemigo. Acuerden las carpetas de antemano. Aquí hay una opción popular para un proyecto TypeScript: