javascript coding-style node.js

javascript - ¿Guía de estilo de codificación para las aplicaciones node.js?



coding-style (7)

Airbnb tiene una guía de estilo de Javascript bastante buena https://github.com/airbnb/javascript

¿Hay una (o varias) guías de estilo de codificación para node.js? Si no, ¿cuáles son los estilos emergentes utilizados por los mejores proyectos de nodo de código abierto?

Estoy buscando una guía (o varias guías) a lo largo de las líneas de PEP 8 , la Guía de estilo de codificación canónica para Python. He visto varias guías de JavaScript que no vale la pena vincular aquí (en su mayoría antiguas y dirigidas al JavaScript del lado del cliente). Encontré una guía de estilo node.js interesante.

Una guía de estilo de codificación, o convenciones de codificación, debe incluir (pero no está limitada a):

  • Diseño de código: sangría (2 espacios, 4 espacios, pestañas, ...), saltos de línea, saltos de línea, etc.
  • Espacio en blanco, por ejemplo, "función (arg)" vs. "función (arg)"
  • Punto y coma o sin punto y coma, declaración var, ...
  • Nombrar, por ejemplo, do_this () vs. doThis (), var_name vs. varName, ...
  • node.js y expresiones idiomáticas de JavaScript, por ejemplo, == vs. ===, la primera arg de la devolución de llamada es un objeto de error, ...
  • Comentarios y documentación
  • Herramientas que lo acompañan, como el verificador de pelusas, el marco de prueba de la unidad, ...

Este tema obviamente es muy subjetivo, pero creo que es un paso importante de una comunidad establecer un estilo de codificación común y ampliamente aceptado en el proceso de maduración. Además, no se trata solo de sabor. En particular, las reglas como "use === en lugar de ==" tienen una influencia directa en la calidad del código.

Al usar un nodo desde el terminal, es útil que el código fuente use espacios para la sangría. De lo contrario, el símbolo de "error aquí" no se alineará.

Con pestañas:

var preps = files.map(function(f) { ^ TypeError: Cannot call method ''map'' of null

Con espacios:

var preps = files.map(function(f) { ^ TypeError: Cannot call method ''map'' of null

Esto podría ser un problema exclusivo de Mac, pero sospecho que no.

Ha pasado un tiempo desde que hice esta pregunta ... y mientras tanto he encontrado esta excelente guía de JavaScript:

Principios de redacción de JavaScript consistente e idiomático

https://github.com/rwldrn/idiomatic.js/

Para Coffee-Script, donde las malas sangrías significan errores de compilación

utilizar

:set tabstop=2 :set shiftwidth=2 :set expandtab

proyectos de café populares, zombie , brunch utiliza esta configuración para las sangrías.

Editar:

¡En realidad, solo usa esto! https://github.com/paulmillr/code-style-guides (uno de los principales contribuyentes al brunch )

Puede aprender muchas buenas prácticas de estilo de codificación de las guías de JavaScript orientadas al cliente (la mayoría de ellas también se aplican a node.js en general, ya que la diferencia entre el cliente y el servidor se encuentra principalmente en bibliotecas y no en el lenguaje). Por ejemplo, el libro JavaScript Patterns dedica a este tema algunas partes del Capítulo 2 . También el website , el book y los videos Douglas Crockford son materiales imprescindibles para adoptar estilos de codificación específicos de JavaScript y las mejores prácticas que diría.

JSLint estándares de codificación JSLint por JSLint o miraría al autor de los estándares de codificación de NPM (Isaac Shlueter).

También puede ver el estilo utilizado por los codificadores notables Node.JS:

Voy a arrojar el mío allí para una buena medida;)

Editar: Sugerencias de

OMI hay algunas reglas de oro que debes seguir:

  • Nunca usar with o eval
  • Use === sobre ==
  • Siempre declare sus variables con var en el alcance apropiado - no retroceda al alcance global
  • Envuelva su aplicación en un cierre (function(){})() si planea liberar el código que se ejecuta en el servidor así como en el navegador
  • Las rellamadas deberían tomar err como primer argumento y si ellas mismas toman una devolución de llamada como argumento, deberían ser las últimas, p. Ej callback(err, param1, param2, callback)

Las sangrías, el espaciado entre llaves y las palabras clave y la ubicación del punto y coma son todas una cuestión de preferencia.