Cómo hacer que tu código en TypeScript se vea más profesional.

En mis primeros años como desarrollador front-end, formaba parte de un equipo de desarrolladores en el que los Tech Leads estaban muy preocupados por "limpiar" el código.

En retrospectiva, entiendo lo que me pedían: que mi código tenía que ser muy descriptivo para que cualquiera pudiera entenderlo. Si alguien revisaba mi código, debía darse cuenta rápida y fácilmente de cómo resolvíamos las historias de usuario del cliente. El resultado final sería un código legible y mantenible.

¿Y cómo podríamos conseguirlo? Bueno, no es tan complicado y los Tech Leads tenían razón, necesitábamos código limpio. Desde entonces he tenido mentores que me han ayudado mucho, y me han ayudado a destapar un deseo de aprendizaje continuo que continúa hasta el día de hoy utilizando ciertos cursos y libros. Y, el concepto de escribir código limpio se me ha quedado grabado.

En este post, me centro en algunos puntos que debemos tener en cuenta a la hora de escribir código limpio, centrándome en TypeScript.

Recuerde, el "mal código" o código espagueti no significa que el código no es utilizable. Pero como programadores, creo que debemos producir software reutilizable, legible y refactorizable.

No añadas contexto innecesario

Si el nombre de tu clase/tipo/objeto te dice algo, no lo repitas en el nombre de tu variable.

Deberías evitarlo:

type Car = {
  carMake: string;
  carModel: string;
  carColor: string;
}

function print(car: Car): void {
  console.log(`${car.carMake} ${car.carModel} (${car.carColor})`);
}

Haz esto en su lugar:

 type Car = {
  make: string;
  model: string;
  color: string;
}

function print(car: Car): void {
  console.log(`${car.make} ${car.model} (${car.color})`);
}

Utilizar enum

Los enums pueden ayudarte a documentar la intención del código. Por ejemplo cuando nos preocupa que los valores sean diferentes en lugar del valor exacto de los mismos.

Debe evitarse:

const GENRE = {
  ROMANTIC: 'romantic',
  DRAMA: 'drama',
  COMEDY: 'comedy',
  DOCUMENTARY: 'documentary',
}

projector.configureFilm(GENRE.COMEDY);

class Projector {
  // declaration of Projector
  configureFilm(genre) {
    switch (genre) {
      case GENRE.ROMANTIC:
        // some logic to be executed 
    }
  }
}

Haz esto en su lugar:

enum GENRE {
  ROMANTIC,
  DRAMA,
  COMEDY,
  DOCUMENTARY,
}

projector.configureFilm(GENRE.COMEDY);

class Projector {
  // declaration of Projector
  configureFilm(genre) {
    switch (genre) {
      case GENRE.ROMANTIC:
        // some logic to be executed 
    }
  }

Los nombres de las funciones deben decir lo que hacen

Deben evitarse:

function addToDate(date: Date, month: number): Date {
  // ...
}

const date = new Date();

// It's hard to tell from the function name what is added
addToDate(date, 1);

Podrías hacer esto

function addMonthToDate(date: Date, month: number): Date {
  // ...
}

const date = new Date();
addMonthToDate(date, 1);

Preferir la programación funcional a la imperativa

Debería evitar:

const contributions = [
  {
    name: 'Uncle Bobby',
    linesOfCode: 500
  }, {
    name: 'Suzie Q',
    linesOfCode: 1500
  }, {
    name: 'Jimmy Gosling',
    linesOfCode: 150
  }, {
    name: 'Gracie Hopper',
    linesOfCode: 1000
  }
];

let totalOutput = 0;

for (let i = 0; i < contributions.length; i++) {
  totalOutput += contributions[i].linesOfCode;
}

Una mejor práctica podría ser

const contributions = [
  {
    name: 'Uncle Bobby',
    linesOfCode: 500
  }, {
    name: 'Suzie Q',
    linesOfCode: 1500
  }, {
    name: 'Jimmy Gosling',
    linesOfCode: 150
  }, {
    name: 'Gracie Hopper',
    linesOfCode: 1000
  }
];

const totalOutput = contributions
  .reduce((totalLines, output) => totalLines + output.linesOfCode, 0);

Evitar los condicionales negativos

Se deben evitar:

function isEmailNotUsed(email: string): boolean {
  // ...
}

if (isEmailNotUsed(email)) {
  // ...
}

Se podría sustituir por

function isEmailUsed(email: string): boolean {
  // ...
}

if (!isEmailUsed(email)) {
  // ...
}

Prefiero la inmutabilidad

Debería evitar:

interface Config {
  host: string;
  port: string;
  db: string;
}

Se puede modificar a

interface Config {
  readonly host: string;
  readonly port: string;
  readonly db: string;
}

tipo vs. interfaz (Type vs Interfaces)

Utilices un tipo cuando necesite una unión o intersección. Utiliza una interfaz cuando quieras extends o implements. No hay una regla estricta, sin embargo, utiliza la que más te convenga.

Debe evitarse:

interface EmailConfig {
  // ...
}

interface DbConfig {
  // ...
}

interface Config {
  // ...
}

//...

type Shape = {
  // ...
}

Haz esto en su lugar:

type EmailConfig = {
  // ...
}

type DbConfig = {
  // ...
}

type Config  = EmailConfig | DbConfig;

// ...

interface Shape {
  // ...
}

class Circle implements Shape {
  // ...
}

class Square implements Shape {
  // ...
}

Un único concepto por prueba

Las pruebas también deben seguir el principio de responsabilidad única. Hacer una sola afirmación por prueba unitaria.

Debe evitarse:

import { assert } from 'chai';

describe('AwesomeDate', () => {
  it('handles date boundaries', () => {
    let date: AwesomeDate;

    date = new AwesomeDate('1/1/2015');
    assert.equal('1/31/2015', date.addDays(30));

    date = new AwesomeDate('2/1/2016');
    assert.equal('2/29/2016', date.addDays(28));

    date = new AwesomeDate('2/1/2015');
    assert.equal('3/1/2015', date.addDays(28));
  });
});

Una mejor práctica podría ser

import { assert } from 'chai';

describe('AwesomeDate', () => {
  it('handles 30-day months', () => {
    const date = new AwesomeDate('1/1/2015');
    assert.equal('1/31/2015', date.addDays(30));
  });

  it('handles leap year', () => {
    const date = new AwesomeDate('2/1/2016');
    assert.equal('2/29/2016', date.addDays(28));
  });

  it('handles non-leap year', () => {
    const date = new AwesomeDate('2/1/2015');
    assert.equal('3/1/2015', date.addDays(28));
  });
});

Conclusión

Hay toneladas de cosas que decir sobre el código limpio, un artículo no es suficiente, sin embargo; es de suma importancia ir cada día mejorando.

Fuente