Muchas veces nos encontramos ante código ilegible o imcomprensible por diversas razones. Este breve artículo intentará abarcar una cierta parametrización de alerta con fin de que de aquí en más, nuestro código sea limpio, legible y entendible.

Todo lenguaje de programación tiene una sintáxis a la cual adherirse. Según la tecnología que trabajemos, existirán ciertas convenciones o nomenclaturas de nombramiento u orden que los componentes interconectados en nuestra aplicación deberán respetar.

Por practicidad, los ejemplos a continuación estarán escritos para una aplicación de Node basada en una arquitectura en capas, sin embargo, conceptualmente, se puede trasladar a cualquier tecnología.

Nomenclatura o convenciones para un código consistente

Variables y funciones:

Siempre deben escribirse en camelCase, haciendo referencia explícita a lo que se alojará en ellas. Esto aplica también para las carpetas (salvo por el camelCase, que no).

// BAD PRACTICE
const products = await productRepository.getPrimaries();

function search () {
   // search some products
}

// GOOD PRACTICE
const primaryProducts = await productRepository.getPrimaries();

function searchProducts () {
   // search some products
}

Una práctica habitual trabajando en Node, es hacer el uso de clases de la siguiente manera:

class search () {
   constructor() {}

   async products() {
      // search some products
   }

   async categories() {
      // search some categories
   }
}

module.exports = new searchMethods();


// USAGE
const search = require(...path);

const products = search().products();

De esta forma, entendemos que, nuestra clase search, tiene un método para buscar productos, otro para buscar categorías, etc. Entonces no es necesario declarar una función llamada searchProducts.

Habiendo visto estos puntos sencillos, pero que muchas veces suelen olvidarse, podemos resumir que la importancia general está en el correcto nombramiento de las cosas.

Parámetros de alerta

• Si maneja lógica de negocios ⇒ Services
• Si necesita usar request o response ⇒ Controller
• Si necesita interactuar con la base de datos ⇒ Repository
• Si solo define el modelo de la base de datos ⇒ Model
• Si se usa para configurar o exponer datos especificos ⇒ Config

Cabe destacar que estos parámetros si bien aplican a arquitecturas de software como en capas, o modular, pueden haber situaciones donde dichos parámetros se desvirtuen un poco en cuánto al lugar donde se alojarán, pero no a lo que hacen referencia.

Cuando trabajamos sobre arquitectura en capas tenemos el formato mencionado en los parámetros de alerta, mientras que si fuese modular, tendríamos todas las funciones (services, controllers, repositories, etc), por módulo. Así mismo, tendría ciertos cambios si fuese hexagonal.

¡Hasta pronto 👋!

Si deseas colaborar con el contenido, regalame un cafecito ☕