Durante los últimos cinco años, he intentado constantemente mejorar mis habilidades de codificación, y una de ellas fue aprender y seguir los estilos de codificación más recomendados.
Esta guía tiene como objetivo ayudarle a escribir código coherente y elegante e incluye algunos consejos para mejorar la legibilidad y el mantenimiento del código. Está inspirado en las pautas populares más aceptadas dentro de la comunidad pero tiene algunas modificaciones para adaptarse mejor a mis preferencias.
Vale la pena mencionar que soy un desarrollador de JavaScript completo y todas mis notas son específicas de mi pila tecnológica (MEVN) y es posible que no sean aplicables a otras pilas.

Reglas generales

Evite la duplicación de código

Si es necesario escribir el mismo bloque de código (o con algunas diferencias manejables) en más de un lugar, es esencial fusionarlos en una función y, de ahora en adelante, llamar a la función cuando sea necesario.

Considere el acoplamiento flojo

Las funciones deben funcionar de forma independiente, lo que significa que editar una no debe tener ningún efecto en las demás, siempre y cuando la entrada y las salidas sigan siendo las mismas. Cada función debe tener ningún conocimiento de las definiciones de las demás y funcionar como un componente separado. En esta situación, todo lo que conoce son sus parámetros y no importa quién llame a la función, las mismas entradas siempre devuelven los mismos resultados.

Declaración

En primer lugar, recuerda declarar las variables todo el tiempo.
Utilice la palabra clave const cuando no se vaya a reasignar una variable. Sin embargo, aún puedes usar const para variables que sean objetos o matrices, incluso si planeas reasignar sus elementos anidados.
Tenga en cuenta que debe requerir módulos y definir variables constantes utilizando siempre la palabra clave const.
Utilice la palabra clave let cuando no pueda usar const y solo utilice la palabra clave var si necesita admitir navegadores más antiguos.

Funciones

Las funciones deben limitarse a lo siguiente:

• Cuatro variables
• Cuatro parámetros
• Treinta líneas de código (ignorando comentarios)
• Cuatro ramas (if-else, while, for, or-and, switch-case)

Las líneas de código deben limitarse a 100 caracteres y, para agrupar/organizar las funciones, es mejor mantener las funciones relacionadas lo más cerca posible una de otra.
Privilegiar la sintaxis de la función de flecha a la alternativa tradicional siempre que sea posible.

Instrumentos de cuerda

Utilice comillas simples ' (en lugar de comillas dobles ") para las cadenas literales ordinarias, pero para cadenas con variables/expresiones incrustadas, cadenas de varias líneas y cadenas que contienen caracteres de comillas simples, utilice literales de plantilla.

Nombrar

Es esencial mantener la coherencia al nombrar las variables. Significa que si variables en diferentes páginas son responsables de los mismos datos, deben tener el mismo nombre.

Los nombres de las variables, funciones, métodos y parámetros deben ser autodescriptivos, lo que significa que cualquiera debería poder saber (o al menos hacer una suposición justa) sobre los datos contenidos con solo mirar sus nombres.

Las variables constantes deben estar en mayúsculas, con las palabras separadas por guiones bajos. Las funciones, variables y métodos deben seguir la sintaxis de camelCase, mientras que las clases e identificadores de CSS deben seguir la sintaxis de kebab-case.

Comentarios

Los comentarios siempre deben comenzar con una letra mayúscula y limitarse a 100 caracteres. Quizás recuerdes que las líneas de código seguirían la misma regla, pero ten en cuenta que si las líneas incluyen ambas, solo pueden exceder los 150 caracteres.
Los comentarios que describen las funciones no deben escribirse donde se llaman sino donde se definen.

Coloque los comentarios después de los códigos de una línea a menos que la longitud de la línea supere los 150 caracteres. En tales casos, y para códigos de varias líneas, coloque los comentarios en la parte superior.

En cuanto a las declaraciones if, los comentarios deben colocarse después de las declaraciones condicionales.

if (conditionIsTrue) { // Put your comment here
    doSomeThing();
} else { // Put your comment here
    doSomethingElse();
}

Recuerde usar barras dobles // para comentarios de una línea y /* */ para comentarios de varias líneas. Al agregar comentarios de varias líneas a códigos de una sola línea o declaraciones condicionales, colóquelos dentro de /* */ de modo que /* se escriba delante del código, el comentario comience en la siguiente línea y */ se escriba en una nueva línea.

if (conditionIsTrue) { /*
        Put your comment here
        Put your comment here
    */
    doSomeThing();
}

functionName(parameter), /*
    Put your comment here
    Put your comment here
*/

Comentarios descriptivos de funciones

Coloque los comentarios encima de las funciones envueltas por /** */.

• Describe los parámetros usando @param {tipo} descripción del nombre de variable.
• Si el parámetro puede aceptar más de un tipo de variable, use @param {type1 | tipo2} descripción del nombre de la variable.
• Si el parámetro es opcional y podría estar ausente, utilice la descripción @param {tipo} [nombre de la variable].
• Si el parámetro tiene un valor predeterminado (debe ser opcional para poder tener un valor predeterminado), use @param {tipo} [variableName="valor"] descripción.
• Describe la salida de la función usando la descripción @returns {tipo}.

/**
 * Describing the function here
 * @param {type} normalVariable A normal variable
 * @param {type1 | type2} multiTypeVariable A variable with multiple expected types
 * @param {type} [variableWithDefaultValue="value"] An optional variable that has a default value in case of being absent when calling the function 
 * @param {type} [optionalVariable] An optional variable
 * @returns {type} description
*/
const functionName = (normalVariable, multiTypeVariable, variableWithDefaultValue, optionalVariable) => {
    doSomeThing();
}

Con respecto a las funciones del servidor con parámetros req y res, no es necesario describir los parámetros de solicitud; solo describe la respuesta usando la descripción @returns.

/**
 * Describing the function here
 * @returns description
 */
functionName = (req, res) => {
    doSomeThing();
}

Generalmente, no es necesario describir los parámetros req, res, next, to y from.

En archivos HTML, use para separar diferentes partes del código; de esta manera el usuario podría identificar cada pieza fácilmente.

En caso de que escribas comentarios en medio de una línea de código, usa /* */.

const calc_result = (firstNumber * secondNumber)/* Explain the reason for the multiplication */   thirdNumber;

Sangría

Los espacios en blanco al final están prohibidos.
Recuerde siempre poner espacios alrededor de expresiones, operadores y símbolos, y también después de comas y llaves, si no son los últimos caracteres de la línea.
Las líneas vacías solo se permiten (y son obligatorias) al final del archivo (todos los archivos deben terminar en una línea vacía), después del último módulo importado, separando las etiquetas Plantilla, Script y Estilo, y entre conjuntos de reglas CSS.
Recuerde usar Tabulador para sangría y Espacio para alineación.

Orden

• Ordene las variables de los esquemas de mangosta y el Vue Reactive State de los componentes en orden alfabético, pero durante el resto del tiempo ordene las líneas de la más corta a la más larga.
• Ordene los métodos de ruta en el orden de poner, obtener, publicar y eliminar, mientras que cada uno está en orden alfabético y todas las rutas deben agruparse según sus URL.

Resumen

Si bien obviamente estos no son los mejores consejos que existen, creo que ofrecen un punto de partida sólido para cualquier persona interesada en aprender los principios del código limpio.
Además, aunque cumplir estrictamente estas reglas puede parecer un desafío al principio, se vuelve mucho más sencillo con la práctica.

Es esencial enfatizar la necesidad de ceñirse a las pautas del proyecto actual cuando se trabaja en un código base a largo plazo, incluso si son insuficientes. Si realmente quiere revisar las pautas del proyecto, considere las modificaciones más beneficiosas y permita que se incorporen gradualmente al proyecto.

Crédito de la imagen de portada: Foto de luis gomes de Pexels