5 sugerencias de programación para js

5 patrones de programación que me gustan

solo algunos patrones

11 de mayo de 2019

Foto de Desmond Simon en Unsplash

En esta publicación me meto en algunos patrones que trato de usar durante la programación. Estos patrones son observaciones que hice sobre mí mismo recientemente mientras trabajaba, así como un par que robé a mis compañeros de trabajo a lo largo de los años.

Estos patrones no están en ningún orden en particular, solo una colección simple.

1. Salidas anticipadas

function transformData(rawData) {
  // check if no data
  if (!rawData) {
    return [];
  }

  // check for specific case
  if (rawData.length == 1) {
    return [];
  }

  // actual function code goes here
  return rawData.map((item) => item);
}

Yo llamo a este patrón "salidas anticipadas", pero algunos también se refieren a esto como "el patrón de Bouncer" o "cláusulas de protección" . Dejando de lado el nombre, este patrón adopta el enfoque de verificar primero los casos de uso no válidos y regresar de esa función; de lo contrario, continúa en el caso de uso esperado de la función y se ejecuta.

Para mí, este enfoque tiene algunos aspectos positivos que realmente me gustan:

alienta a pensar en casos no válidos / extremos y cómo se deben manejar esos casos
evita el procesamiento accidental e innecesario del código en un caso de uso inesperado
mentalmente me permite procesar cada caso de uso mucho más claramente
una vez adoptado, puede echar un vistazo rápidamente a las funciones y comprender el flujo y la ejecución que generalmente sigue un enfoque de arriba hacia abajo que va desde - casos inválidos -> casos pequeños -> caso esperado

Más información:

El patrón de gorila de Rik Schennink

2. Cambiar a objeto literal

// Switch
let createType = null;
switch (contentType) {
  case "post":
    createType = () => console.log("creating a post...");
    break;
  case "video":
    createType = () => console.log("creating a video...");
    break;
  default:
    createType = () => console.log('unrecognized content type');
}

createType();

// Object literal
const contentTypes = {
  post: () => console.log("creating a post..."),
  video: () => console.log("creatinga  video..."),
  default: () => console.log('unrecognized content type')
};

const createType = contentTypes[contentType] || contentTypes['default'];
createType();

El siguiente paso es eliminar el switch. A menudo cometo errores al escribir todos case y muy a menudo olvido un break. Esto provoca todo tipo de problemas divertidos. La switch declaración no agrega mucho valor cuando estoy escribiendo código. Parece interponerse en el camino.

Prefiero usar un objeto literal en su lugar, he aquí por qué:

no tienes que preocuparte por case o break
más fácil de leer y comprender rápidamente lo que está sucediendo
los literales de objeto son bastante fáciles de escribir
menos código

Más información:

3. Un bucle de dos matrices

const exampleValues = [2, 15, 8, 23, 1, 32];
const [truthyValues, falseyValues] = exampleValues.reduce((arrays, exampleValue) => {
  if (exampleValue > 10) {
    arrays[0].push(exampleValue);
    return arrays;
  }

  arrays[1].push(exampleValue);
  return arrays;
}, [[], []]);

Este patrón no es nada especial y debería haberme dado cuenta antes, pero me encontré filtrando una colección de elementos para obtener todos los elementos que coincidían con una determinada condición, y luego volviéndolo a hacer para una condición diferente. Eso significaba recorrer una matriz dos veces, pero podría haberlo hecho una vez.

Resulta que esto tiene un nombre (bifurcado) y lo robé de 30secondsofcode.org . Si nunca ha visitado ese sitio, le sugiero que vaya allí. Mucha buena información y código útil.

Sé que reducir puede ser un poco abrumador y no muy claro lo que está sucediendo, pero si puede sentirse cómodo con él, realmente puede aprovecharlo para construir cualquier estructura de datos que necesite mientras recorre una colección. Realmente deberían haberlo llamado en builder lugar de reduce.

Más información:

30secondsofcode.org

4. Sin variables "foo"

// bad
const foo = y && z;

// good
const isPostEnabled = isPost && postDateValid;

Este puede parecer un poco obvio, pero estoy seguro de que todos hemos visto código que hace esto. Tómese el tiempo y haga todo lo posible para nombrar algo de manera apropiada.

Esto es especialmente importante para los profesionales que trabajan o para las personas que se encuentran en una posición en la que están educando a otros. La denominación de variable debe usarse para ayudar a explicar y dar contexto a lo que está sucediendo dentro del código.

Alguien debería ser capaz de leer su código y comenzar a comprender libremente lo que se intenta resolver.

Más información:

El arte de nombrar variables por Richard Tan

5. Ternaries anidados

let result = null;
if (conditionA) {
  if (conditionB) {
    result = "A & B";
  } else {
    result = "A";
  }
} else {
  result = "Not A";
}

const result = !conditionA
  ? "Not A"
  : conditionB
  ? "A & B"
  : "A";

Lo admito, al principio la idea de anidar ternaries era desagradable. Parecía una forma inteligente de escribir condicionales. Luego comencé a escribir lógica de negocios y me encontré con cláusulas if else anidadas y una lógica condicional bastante cuestionable.

Creo if y else son mucho más fáciles de leer, ya que son palabras reales pero cuando estos se convierten anidado comienzo a tener realmente un momento difícil después de lo que está pasando y mantener un seguimiento de todo mentalmente.

Comencé a diferirme de ternaries y ternaries anidados y descubrí que podía entender rápidamente de un vistazo lo que estaba sucediendo.

Creo que este patrón realmente depende de usted, su equipo y sus preferencias. He trabajado en bases de código que funcionan bien y puedo ver ambos lados de esto, pero los ternaries anidados personalmente realmente me están creciendo.