JavaScript Standard Style
Sponsored by
English • Español (Latinoamérica) • Français • Bahasa Indonesia • Italiano (Italian) • 日本語 (Japanese) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin)
Guía de estilos JavaScript, con linter y corrección automática de código
Este módulo te ahorra tiempo a ti (y otros) tres maneras:
- Sin configuración. La manera más fácil de usar estilos consistentes en tu proyecto.
- Automáticamente formatea el código. Ejecuta
standard --fix
y dile adiós a las inconsistencias en tu código. - De manera temprana captura problemas de estilos y errores de programador. Te ahorras el tiempo de hacer revisiones de código eliminando inconsistencias entre el dueño del repositorio y los contribuidores.
Instalar con:
npm install standard --save-dev
Las reglas son:
- 2 espacios como sangría.
- Usar comillas simples en cadenas de texto con la excepción de escapado de texto
- No dejar variables sin usar – esta captura toneladas de bugs!
- Sin punto y coma – Está bien. ¡En serio!
- Nunca empezar una línea con
(
,[
, o`
- Este es el único problema al evitar punto y coma – automáticamente verificado para ti! - Espacio después de las palabras claves
if (condition) { ... }
- Espacio después del nombre de función
function name (arg) { ... }
- Usar siempre
===
en vez de==
– peroobj == null
está permitido para verificarnull || undefined
. - Gestionar siempre el parámetro de función
err
de node.js - Usar siempre el prefijo
window
en los globales del navegador – A excepción dedocument
ynavigator
esto está bien- Previene el uso accidental de mal-llamados globales del navegador como
open
,length
,event
, yname
.
- Previene el uso accidental de mal-llamados globales del navegador como
- Y mucho más – prueba
standard
hoy mismo!
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
!
Tabla de Contenido
-
Inicio Rápido
-
FAQ
- ¿Por qué debería usar JavaScript Standard Style?
- ¿Quién usa JavaScript Standard Style?
- ¿Hay plugins para editores de textos?
- ¿Hay alguna medalla para al readme?
- No estoy de acuerdo con la regla X, ¿la puedo cambiar?
- ¡Pero esto no un estandar web real!
- ¿Hay algún formateador automático?
- ¿Cómo hago para ignorar archivos?
- ¿Cómo oculto cierta alerta?
- Yo uso una librería que contamina el espacio de nombres global. ¿Cómo puedo evitar los errores "variable is not defined"?
- ¿Puedo usar un parser JavaScript que soporte ES última-generación?
- ¿Puedo usar una variación de lenguaje JavaScript, como Flow?
- ¿Qué pasa con Mocha, Jasmine, QUnit y etc?
- ¿Qué pasa con Web Workers?
- ¿Puedo verificar código dentro de archivos Markdown o HTML?
- ¿Hay algún gancho git
pre-commit
? - ¿Cómo hago la salida (output) toda colorida y bonita?
- Node.js API
- ¿Cómo puedo contribuir a
standard
?
Instalación
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.
Uso
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
.
Lo que podrías hacer si eres inteligente
-
Agregar esto
package.json
{ "name": "my-cool-package", "devDependencies": { "standard": "*" }, "scripts": { "test": "standard && node my-tests.js" } }
-
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 '=='.
-
No vuelvas a dar feedback de estilos en una PR jamás!
¿Por qué debería usar JavaScript Standard Style?
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:
- Sin configuración. La manera más fácil de usar estilos consistentes en tu proyecto.
- Automáticamente formatea el código. Ejecuta
standard --fix
y dile adiós a las inconsistencias en tu código. - Captura problemas de estilos y errores del programador muy pronto. Te ahorras el tiempo de hacer revisiones de código eliminando inconsistencias entre el dueño del repositorio y los contribuidores.
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.
¿Quién usa JavaScript Standard Style?
¡Un montón de gente!
Your logo here | Your logo here | Your logo here |
---|
Adicionalmente a compañías, muchos miembros de la comunidad usan standard
en módulos que son
muy numerosos para listar aquí.
También standard
es el linter con más estrellas en GitHub
Clean Code Linter.
¿Hay plugins para editores de textos?
Primero, instale standard
. Luego, instale el plugin apropiado para su editor:
Sublime Text
Usando Package Control, instale SublimeLinter y SublimeLinter-contrib-standard.
Para formateo automático al guardar, instale StandardFormat.
Atom
Instale linter-js-standard.
Para formateo automático al guardar, instale standard-formatter. Para snippets, instale standardjs-snippets.
Visual Studio Code
Instale vscode-standard. (Incluye soporte para formateo automático.)
Para snippets JS, instale: vscode-standardjs-snippets. Para snippets React, instale vscode-react-standard.
Vim
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
Emacs
Instale Flycheck y revise manual para aprender como habilitarlo en sus proyectos.
Brackets
Busque el registro de extension para "Standard Code Style".
WebStorm and other JetBrains products
WebStorm recientemente anuncio soporte nativo para standard
directamente en el IDE.
Si aun prefieres configurar standard
manualmente sigue esta guía. Esto se aplica a todos los productos de JetBrains, incluyendo PhpStorm, IntelliJ, RubyMine y etc.
Hay alguna medalla para readme?
Si! Si estas usando standard
en tu proyecto, puedes incluir 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/standard/standard/master/badge.svg)](https://github.com/standard/standard)
[![Standard - JavaScript Style Guide](https://img.shields.io/badge/code%20style-standard-brightgreen.svg)](https://standardjs.com/)
No estoy de acuerdo con la regla X, ¿la puedo cambiar?
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
¡Pero esto no es un estandar web real!
¡Por supuesto que no lo es! Este estilo no está afiliado a ningún grupo oficial de estándar web, por eso este repositorio se llama standard/standard
y no ECMA/standard
.
La palabra “estándar” tiene más significados que solo “estándar web” :-) Por ejemplo:
- Este módulo ayuda a mantener el código a la más alta calidad estándar.
- Este módulo asegura que las nuevas contribuciones sigan los estilos estándar básicos.
¿Hay algún formateador automático?
¡Sí! Puedes usar standard --fix
para arreglar la mayoría de los 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.
¿Cómo hago para ignorar archivos?
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"
]
}
¿Cómo oculto cierta alerta?
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.
Inhabilitar toda las reglas en una línea específica:
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 líneas:
/* 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 */
Yo uso una librería que contamina el espacio de nombres global. ¿Cómo puedo evitar los errores "variable is not defined"?
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, sería 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
¿Cómo puedo usar características experimentales JavaScript (ES Next)?
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-parser
) y ejecuta esto:
$ standard --parser @babel/eslint-parser
O, agrega esto a package.json
:
{
"standard": {
"parser": "@babel/eslint-parser"
}
}
Si standard
está instalado globalmente (ej: npm install standard --global
), entonces asegúrate de instalar @babel/eslint-parser
globalmente también com npm install @babel/eslint-parser --global
.
¿Puedo usar una variación de lenguaje JavaScript, como Flow?
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-parser",
"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
¿Qué pasa con Mocha, Jasmine, QUnit y etc?
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
¿Qué pasa con Web Workers?
Agrega esto al inicio de tus archivos:
/* eslint-env serviceworker */
Esto le hará saber a standard
(como también humanos que leen tu código) que
self
es una variable global en el código web worker.
¿Puedo verificar código dentro de archivos Markdown o HTML?
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'
¿Hay algún gancho git pre-commit
?
¡Qué bien que lo preguntes!
# Asegura que todos los archivos javascript especificados
function xargs-r() {
# Portable version of "xargs -r". The -r flag is a GNU extension that
# prevents xargs from running if there are no input files.
if IFS= read -r -d $'\n' path; then
echo "$path" | cat - | xargs "$@"
fi
}
git diff --name-only --cached --relative | grep '\.jsx\?$' | sed 's/[^[:alnum:]]/\\&/g' | xargs-r -E '' -t standard
if [[ $? -ne 0 ]]; then
echo 'JavaScript Standard Style errors were detected. Aborting commit.'
exit 1
fi
¿Cómo hago la salida (output) toda colorida y bonita?
La salida integrada es simple y directa, pero si te gustan las cosas brillantes, puedes instalar snazzy:
$ npm install snazzy
y ejecutar:
$ standard | snazzy
También tienes standard-tap, standard-json, standard-reporter, y standard-summary.
Node.js API
async standard.lintText(text, [opts])
Hacer Lint al texto fuente previsto para hacer cumplir JavaScript Standard Style.
Un objeto opts
puede ser proporcionado:
{
// unique to lintText
filename: '', // path of file containing the text being linted
// common to lintText and lintFiles
cwd: '', // current working directory (default: process.cwd())
fix: false, // automatically fix problems
extensions: [], // file extensions to lint (has sane defaults)
globals: [], // custom global variables to declare
plugins: [], // custom eslint plugins
envs: [], // custom eslint environment
parser: '', // custom js parser (e.g. babel-eslint)
usePackageJson: true, // use options from nearest package.json?
useGitIgnore: true // use file ignore patterns from .gitignore?
}
results
objeto :
const results = {
results: [
{
filePath: '',
messages: [
{ ruleId: '', message: '', line: 0, column: 0 }
],
errorCount: 0,
warningCount: 0,
output: '' // fixed source code (only present with {fix: true} option)
}
],
errorCount: 0,
warningCount: 0
}
async standard.lintFiles(files, [opts])
Hacer Lint a los archivos que concuerden con el patrón globs.
Un objeto opts
puede ser proporcionado:
{
// unique to lintFiles
ignore: [], // file globs to ignore (has sane defaults)
// common to lintText and lintFiles
cwd: '', // current working directory (default: process.cwd())
fix: false, // automatically fix problems
extensions: [], // file extensions to lint (has sane defaults)
globals: [], // custom global variables to declare
plugins: [], // custom eslint plugins
envs: [], // custom eslint environment
parser: '', // custom js parser (e.g. babel-eslint)
usePackageJson: true, // use options from nearest package.json?
useGitIgnore: true // use file ignore patterns from .gitignore?
}
Objeto results
(igual al de arriba).
¿Cómo puedo contribuir a standard
?
¡Las contribuciones son bienvenidas! Comprueba los issues o PRs, o haz el tuyo propio si quieres algo que nos ves allí
Únete a nosotros #standard
en freenode.
- standard - este repositorio
- standard-engine - motor arbitrario cli de relgas eslint
- eslint-config-standard - reglas eslint para standard
- eslint-config-standard-jsx - reglas eslint para standard (JSX)
- eslint-plugin-standard - reglas customizadas eslint para standard (no es parte del nucleo eslint)
- eslint - linter que da poder a standard
- snazzy - salida colorida o bonita en el terminal para standard
- standard-www - código de https://standardjs.com
- semistandard - standard, con punto y coma (sí es necesario)
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
.
Licencia
MIT. Copyright (c) Feross Aboukhadijeh.