JavaScript Standard Style

Una guía de estilos JavaScript para gobernarlos a todos

Translations: English, Português, 繁體中文, 简体中文


Este modulo te ahorra tiempo a ti (y otros) tres maneras:

Instalar con:

npm install standard --save-dev

Para una mejor idea, mira este archivo de ejemplo escrito en JavaScript Standard Style. O, mira alguno de los miles de proyectos que usan standard!

La manera más fácil de usar JavaScript Standard Style es instalarlo globalmente como un programa de línea de comandos de Node. Ejecuta el siguiente comando en la terminal:

$ npm install standard --global

O, puedes instalar standard localmente, para usar en un solo proyecto:

$ npm install standard --save-dev

Nota: para ejecutar los comandos anteriores Node.js y npm deben estar instalados.

Una vez tenga instalado standard, ya deberías poder usar standard. Un simple caso de uso podría ser comprobar estilos de todos los archivos JavaScript en el directorio actual:

$ standard
Error: Use JavaScript Standard Style
  lib/torrent.js:950:11: Expected '===' and instead saw '=='.

Opcionalmente puedes pasar un directorio (o directorios) usando el patrón glob. Asegúrese de usar comillas en las rutas que contengan el patrón glob para que sean expandidos por standard y no por el shell:

$ standard "src/util/**/*.js" "test/**/*.js"

Nota: Por defecto standard buscará todos los archivos que concuerden con los patrones: **/*.js, **/*.jsx.

  1. Agregar esto package.json
{
  "name": "my-cool-package",
  "devDependencies": {
    "standard": "*"
  },
  "scripts": {
    "test": "standard && node my-tests.js"
  }
}
  1. Los estilos son comprobados automáticamente cuando ejecutes npm test
$ npm test
Error: Use JavaScript Standard Style
  lib/torrent.js:950:11: Expected '===' and instead saw '=='.
  1. No vuelvas a dar feedback de estilos en una PR jamás!

La belleza de JavaScript Standard Style es qué es simple. Nadie quiere mantener configuración de estilos en múltiples archivos de cientos de líneas para cada módulo/proyecto en los que trabajan. ¡Se acabó esta locura!

Este módulo te ahorra tiempo a ti (y otros) en tres maneras:

Adoptar estilos standard significa clasificar la importancia de la claridad del código y las convenciones de la comunidad mucho más que estilo personal. Esto quizás no tenga sentido para el 100% de proyectos y culturas de desarrollo, pero los proyectos de código abierto pueden llegar a ser hostiles para los novatos. Estableciendo expectativas de contribución limpia y automatizada puede hacer el proyecto más saludable.

Un montón de gente!

Adicionalmente a compañías, muchos miembros de la comunidad usan standard en modulos que son muy numerosos para listar aquí.

También standard es el linter con más estrellas en GitHub Clean Code Linter.

Primero, instale standard. Luego, instale el plugin apropiado para su editor:

Usando Package Control, instale SublimeLinter y SublimeLinter-contrib-standard.

Para formateo automático al guardar, instale StandardFormat.

Instale linter-js-standard.

Para formateo automático al guardar, instale standard-formatter. Para snippets, instale standardjs-snippets.

Instale vscode-standardjs. (Incluye soporte para formateo automático.)

Para snippets JS, instale: vscode-standardjs-snippets. Para snippets React, instale vscode-react-standard.

instale Syntastic y agregue esta línea a su .vimrc:

let g:syntastic_javascript_checkers = ['standard']

Para formateo automático al guardar, agregue estas dos líneas a su .vimrc:

autocmd bufwritepost *.js silent !standard --fix %
set autoread

Instale Flycheck y revise manual para aprender como habilitarlo en sus proyectos.

Busque el registro de extension para "Standard Code Style".

WebStorm and other JetBrains products

WebStorm recientemente anuncio soporte nativo para standard diractemente en el IDE.

Si aun prefieres configurar standard manualmente sigue esta guia. Esto se aplica a todos los productos de JetBrains, incluyendo PhpStorm, IntelliJ, RubyMine y etc.

Si! Si estas usando standard en tu proyecto, puedes includir una de estas en tu readme para hacerle saber a las personas que en tu código estas usando estilos standard.

[![Standard - JavaScript Style Guide](https://cdn.rawgit.com/feross/standard/master/badge.svg)](https://github.com/feross/standard)

[![Standard - JavaScript Style Guide](https://img.shields.io/badge/code%20style-standard-brightgreen.svg)](https://standardjs.com/)

No. El objetivo de standard es evitar bikeshedding en el estilo. Existen un montón de debates online acerca de tabs vs espacios, etc. que nunca serán resueltos. Estos debates solo te distraen de hacer tu trabajo. Al final del día tienes simplemente que “usar alguno”, y esa es toda la filosofía de standard -- es un montón de sensibles opiniones de “usar alguno”. Con la esperanza que los usuarios vean el valor en esto más que defender sus propias opiniones.

Si realmente quieres configurar cientos de reglas individualmente, puedes usar eslint directamente con eslint-config-standard aplicando cambios encima de este.

Tip: ¡Simplemente usa standard y ya está. Existen problemas reales en los cuales debes usar tu tiempo! :P

¡Por su puesto que no lo es! Este estilo no está afiliado a ningún grupo oficial de estándar web, por eso este repositorio se llama feross/standard y no ECMA/standard.

La palabra “estándar” tiene más significados que solo “estándar web” :-) Por ejemplo:

¡Sí! Puedes usar standard --fix para arreglar la mayoría de problemas automáticamente.

standard --fix está integrado en standard (desde v8.0.0) para máxima conveniencia. La mayoría de los problemas se arreglan, pero algunos errores (olvidar gestionar errores en callbacks) deben ser arreglados manualmente.

Para no perder el tiempo, standard emite un mensaje ("Run standard --fix to automatically fix some problems.") cuando detecta errores que pueden ser arreglados automáticamente.

Ciertas rutas (node_modules/, coverage/, vendor/, *.min.js, bundle.js, y archivos/directorios que empiezan con . cómo .git) son ignorados automáticamente.

Las rutas del .gitignore del proyecto raíz son ignorados automáticamente.

A veces necesitas ignorar directorios o archivos específicos. Para hacerlo, agrega la propiedad standard.ignore al package.json:

"standard"{
  "ignore": [
    "**/out/",
    "/lib/select2/",
    "/lib/ckeditor/",
    "tmp.js"
  ]
}

En raros casos, necesitarás romper una regla y ocultar la alerta generada por standard.

JavaScript Standard Style usa ESLint bajo la capucha y puedes ocultar las alertas como normalmente lo harías si usaras ESLint directamente.

Para obtener una salida mas especifica (así puedes encontrar el nombre de la regla a ignorar) ejecute:

$ standard --verbose
Error: Use JavaScript Standard Style
  routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)

Inhabilitar toda las reglas en una linea especifica:

file = 'I know what I am doing' // eslint-disable-line 

O, inhabilitar solo la regla "no-use-before-define":

file = 'I know what I am doing' // eslint-disable-line no-use-before-define 

O, inhabilitar la regla "no-use-before-define" para múltiples lineas:

/* eslint-disable no-use-before-define */
console.log('offending code goes here...')
console.log('offending code goes here...')
console.log('offending code goes here...')
/* eslint-enable no-use-before-define */

Algunos paquetes (ej mocha) colocan sus funciones (ej: describe, it) en el objeto global (¡mala manera!). Como estas funciones no están definidas o requeridas (ej: require) en ningún lugar del código, standard te alertara que están usando una variable que no está definida (usualmente, esta regla es realmente útil para detectar errores de tipeo). Pero queremos inhabilitar estas variables globales.

Para hacerle saber a standard (como también a los humanos que leen tu código) que ciertas variables son globales en tu código, agregar esto en la parte superior de tu código:

/* global myVar1, myVar2 */

Si tienes cientos de archivos, seria deseable evitar agregar comentarios a cada archivo. En este caso ejecute:

$ standard --global myVar1 --global myVar2

O, agregar esto a su package.json

{
  "standard": {
    "globals": [ "myVar1", "myVar2" ]
  }
}

Nota: global y globals son equivalentes

standard soporta las ultimas características de ECMAscript, ES8 (ES2017) incluyendo todas las características del lenguaje de las propuestas que estan en "Stage 4" del proceso de propuestas.

Para soportar características experimentales del lenguaje, standard soporta especificar un parser JS customizado. Antes de que uses un parser customizado, considera si la complejidad agregada vale la pena.

Para usar un parser customizado, instálalo desde npm (ejemplo: npm install babel-eslint) y ejecuta esto:

$ standard --parser babel-eslint

O, agrega esto a package.json:

{
  "standard": {
    "parser": "babel-eslint"
  }
}

Si standard está instalado globalmente (ej: npm install standard --global), entonces asegúrate de instalar babel-eslint globalmente también com npm install babel-eslint --global.

Antes de usar una variable del lenguaje JavaScript customizado, considera si la complejidad agregada (y esfuerzo requerido para obtener los contribuidores alcanzarle con rapidez) vale la pena.

standard soporta plugins ESLint. Usa uno de estos para transformar el código a JavaScript válido antes de que standard lo vea. Para usar un parser customizado, instálalo desde npm (example: npm install eslint-plugin-flowtype) y ejecuta:

$ standard --plugin flowtype

O, agrega esto a package.json:

{
  "standard": {
    "parser": "babel-eslint",
    "plugins": [
      "flowtype"
    ]
  }
}

Si standard está instalado globalmente (ej: npm install standard --global), entonces asegúrate de instalar eslint-plugin-flowtype globalmente también, con npm install eslint-plugin-flowtype -g.

Nota: plugin y plugins son equivalentes

Para soportar mocha en tus archivos de tests, agrega esto al inicio de los archivos:

/* eslint-env mocha */

O, ejecuta:

$ standard --env mocha

Donde mocha puede ser jasmine, qunit, phantomjs, y así sucesivamente. Para ver la lista completa, comprueba la documentación de ESLint especificando entornos. Para una lista de qué variables globales están disponibles en estos entornos comprueba el módulo npm globals.

Nota: env y envs son equivalentes

Agrega esto al inicio de tus archivos:

/* eslint-env serviceworker */

Esto le hará saber astandard (como también humanos que leen tu código) que self es una variable global en el codigo web worker.

Para verificar código dentro de archivos Markdown use standard-markdown.

Alternativamente, hay plugins ESLint para verificar código de Markdown, HTML y otros tipos de lenguajes:

Para verificar código dentro de archivos Markdown, usa el plugin ESLint:

$ npm install eslint-plugin-markdown

Luego para verificar código JS que aparece dentro de bloques código, ejecute:

$ standard --plugin markdown '**/*.md'

Para verificar código dentro de archivos HTML, use el plugin ESLint:

$ npm install eslint-plugin-html

Luego para verificar el código que aparece dentro de etiquetas <script>, ejecute:

$ standard --plugin html '**/*.html'

¡Qué bien que lo preguntes!

#!/bin/sh 
# Asegura que todos los archivos javascript especificados 
# para hacer commit pasan los estandares de estilo de código 
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi

La salida integrada es simple y directa, pero si te gustan las cosas brillantes, puedes instalar snazzy:

$ npm install snazzy

y ejecutar:

$ standard --verbose | snazzy

También tienes standard-tap, standard-json, standard-reporter, y standard-summary.

Hacer Lint al texto fuente previsto para hacer cumplir JavaScript Standard Style. Un objeto opts puede ser proporcionado:

var opts = {
  fix: false,   // automatically fix problems 
  globals: [],  // global variables to declare 
  plugins: [],  // eslint plugins 
  envs: [],     // eslint environment 
  parser: ''    // js parser (e.g. babel-eslint) 
}

El callback será llamado con un objeto de Error y results:

var results = {
  results: [
    {
      filePath: '',
      messages: [
        { ruleId: '', message: '', line: 0, column: 0 }
      ],
      errorCount: 0,
      warningCount: 0
    }
  ],
  errorCount: 0,
  warningCount: 0
}

Hacer Lint a los archivos que concuerden con el patrón globs. Un objeto opts puede ser proporcionado:

var opts = {
  ignore: [],   // file globs to ignore (has sane defaults) 
  cwd: '',      // current working directory (default: process.cwd()) 
  fix: false,   // automatically fix problems 
  globals: [],  // global variables to declare 
  plugins: [],  // eslint plugins 
  envs: [],     // eslint environment 
  parser: ''    // js parser (e.g. babel-eslint) 
}

El callback será llamado con un objeto de Error y results: (igual al de arriba).

Las contribuciones son bienvenidas! Comprueba los issues o PRs, o haz el tuyo propio si quieres algo que nos ves allí

Unete a nosotros #standard en freenode.

También hay un montón plugins editores de textos, una lista de paquetes npm que usan standard, y una impresionante lista de paquetes en el ecosistema standard.

MIT. Copyright (c) Feross Aboukhadijeh.