JavaScript Standard Style

Un solo Stile JavaScript per domarli tutti

EnglishEspañol (Latinoamérica)Italiano (Italian)한국어 (Korean)Português (Brasil)简体中文 (Simplified Chinese)繁體中文 (Taiwanese Mandarin)


Questo modulo fa risparmiare tempo a te (e altri!) in tre modi:

Non ci sono decisioni da prendere. Nessun .eslintrc, jshintrc, o .jscsrc file da mantenere. Funziona e basta.

Installa con:

npm install standard --save-dev

Per avere le idee più chiari, da un'occhiata al file d'esempio scritto usando JavaScript Standard Style. O guarda i millemila progetti che usano standard!

La maniera più semplice per usare JavaScript Standard Style è quella di installarlo globalmente usando la linea di comando di Node. Esegui il seguente comando da terminale:

$ npm install standard --global

O, se vuoi installare standard localmente, da utilizzare in un singolo progetto:

$ npm install standard --save-dev

Nota: per eseguire i precedenti comandi, Node.js and npm deve essere già installato sulla propria macchina.

Dopo aver installato standard, dovresti essere in grado di utilizzarlo come programma. Lo scenario d'uso più comune sarebbe quello di controllare lo stile di tutti i tuoi file JavaScript attualmente presenti nel tuo progetto:

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

Puoi opzionalmente passare una cartella (o cartelle) usando il pattern globale. Assicurati di mettere tra virgolette i percorsi contenenti il pattern globale, così verranno espansi da standard invece che dalla tua shell:

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

Nota: di default standard controllerà tutti i file che corrispondono al seguente pattern: **/*.js, **/*.jsx.

  1. Aggiungerlo al tuo package.json
{
  "name": "my-cool-package",
  "devDependencies": {
    "standard": "*"
  },
  "scripts": {
    "test": "standard && node my-tests.js"
  }
}
 
2. Lo stile del tuo codice verrà controllato automaticamente quando esegui `npm test`
```bash
$ npm test
Error: Use JavaScript Standard Style
  lib/torrent.js:950:11: Expected '===' and instead saw '=='.
  1. Mai più suggerimenti riguardo lo stile del tuo codice durante le pull request!

La bellezza di JavaScript Standard Style è la sua semplicità. Nessuno vuole mantenere migliaia di linee di codice di configurazione per lo stile del codice per ogni progetto/module sul quale si lavora. Basta impazzire!

Questo modulo fa risparmiare tempo a te (e altri!) in tre modi:

Un sacco di gente!

Oltre alle aziende, anche molti membri della comunità usano standard su pacchetti che sono troppo numerosi da mostrare qui.

standard è inoltre il miglior linter favorito dal caso d'uso dalla GitHub Clean Code Linter.

Primo, installa standard. Dopo di che installa il plugin più appropriato per il tuo editor:

Usano Package Control, installa SublimeLinter e SublimeLinter-contrib-standard.

Per la formattazione automatica durante il salvataggio, installa StandardFormat.

Installa linter-js-standard.

In alternativa, puoi installare linter-js-standard-engine. Invece di installare la sua versione di standard, userà automaticamente la version installata all'interno del tuo progetto. Funzionerà automaticamente anche con altri linters che si basano su standard-engine.

Per la formattazione automatica, installa standard-formatter. Per aiuti (snippets), installa standardjs-snippets.

Installa vscode-standardjs. (Include supporto per la formattazione automatica.)

Per JS snippets, installa: vscode-standardjs-snippets. Per ReactJS snippets, installa vscode-react-standard.

Installa ale.

Per la formattazione automatica al salvataggio, aggiungi quelle linee a .vimrc:

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

Pacchetti alternativi che possono essere inclusi sono neomake e syntastic, entrambi hanno all'interno il supporto per standard (configurazione potrebbe essere necessaria).

Installa Flycheck e controlla manual per imparare come abilitarlo all'interno del tuo progetto.

Cerca l'estenzione di registro per "Standard Code Style" and clicca "Install".

WebStorm ha annunciato recentemente supporto nativo per standard direttamente nell'IDE.

Se preferisci configurare standard manualmente, segui questa guida. Questa guida va bene per tutti i prodotti JetBrains, come ad esempio PhpStorm, IntelliJ, RubyMine, ecc.

If you still prefer to configure standard manually, follow this guide. This applies to all JetBrains products, including PhpStorm, IntelliJ, RubyMine, etc.

Sì! Se usi standard nel tuo progetto, puoi includere uno di questi banner nel tuo readme file per far sapere alle persone the il tuo codice usa JavaScript Standard Style.

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

[![JavaScript Style Guide](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](https://standardjs.com)

No. Il punto essenziale di standard è di aiutarti a salvare tempo evitando bikeshedding (discussioni su piccole cose mentre la cosa più importante non è terminata) sullo stile del codice. Ci sono un sacco di grandi discussioni riguardo tabs vs. spazi, ecc. che non saranno mai risolte. Queste discussioni semplicemente fanno perdere tempo. Alla fine, quello che ti rimane da fare è solamente 'scegli qualcosa', è questa la filosofia di standard - un sensato insieme di opinioni di 'scegli qualcosa'. Con un po' di fiducia, gli utenti vedranno il valore in ciò invece di difendere il proprie opinioni personali.

Se davvero vuoi configurare centinaia di regole ESLint individualmente, puoi sempre usare eslint direttamente con eslint-config-standard in modo da usare le tue regole.

Suggerimento: usa semplicemente standard e vai avanti. Ci sono problemi più reali dove puoi spendere il tuo prezioso tempo! :P

Ovvio che no! Lo stile presentato qui non è affiliato con nessuno degli gruppi standard web, ecco perchè questo repository si chiama standard/standard e non ECMA/standard.

La parola "standard" signica più di un "web standard" :-) Per esempio:

Sì! Puoi usare standard --fix per correggere la maggior parte degli errori automaticamente.

standard --fix è direttamente offerto da standard per offrire il massimo della convenienza. La maggior parte degli errori possono essere corretti, ma alcuni errori (come ad esempio dimenticarsi di gestire gli errori) devono essere corretti a mano.

Per risparmiare tempo, l'ouput di standard è un messaggio del tipo "Run standard --fix to automatically fix some problems" quando rileva problemi che possono essere risolti automaticamente.

Alcuni percorsi (node_modules/, coverage/, vendor/, *.min.js, bundle.js, e file/cartelle the iniziano con . come .git/) sono automaticamente ignorati.

Anche i percorsi specificati all'interno del file .gitignore sono automaticamente ignorati.

Alle volte hai bisogno di ignorare file minificati o cartelle in più. Per farlo, aggiungi la proprietà standard.ignore all'interno di package.json:

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

In rari casi, avarai la necessità di rompere le regole e nascondere l'avviso generato da standard.

JavaScript Standard Style usa ESLint al di sotto del suo engine e puoi nascondere gli avvisi come se lo facessi direttamente per ESLint.

Per avere un output più verboso (e così avere accesso al nome della regola), esegui:

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

Disabilita tutte le regole in una specifica riga:

file = 'So cosa sto facendo' // eslint-disable-line 

O, disabilita solo la regola "no-use-before-define":

file = 'So cosa sto facendo'  // eslint-disable-line no-use-before-define 

O, disabilita la regola "no-use-before-define" per più righe:

/* 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 */

Alcune librerie (es. mocha) mettono le loro funzionalità (es. describe, it) nell'oggetto globale. Considerato il fatto che queste funzioni definite o non sono importate usando il require all'interno del tuo codice, standard vi avviserà che stai per utilizzare una variabile che non è non stata definita. (di solito questa regola è utile per trovare errori di scrittura!). Ma vogliamo disabilitarlo per questi oggetti globali.

Per permettere a standard (anche per quando qualcun altro leggerà il tuo codice) di far sapere che certe variabili sono globali all'interno del tuo codice, aggiungi questo all'inizio del tuo file:

/* global myVar1, myVar2 */

Se hai centiaia di file, sarebbe più conveniente evitare di aggiungere commenti su ogni file. In questo caso, esegui:

$ standard --global myVar1 --global myVar2

Oppure aggiungi questo al tuo package.json:

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

Nota: global e globals sono equivalenti.

standard supporta le ultime funzionalità di ECMAScript, ES8 (ES2017), includendo anche funzionalità proposte (proposals) che si trovano allo "Stage 4" del processo decisionale.

Per supportare funzionalità sperimentali, standard permette di configurare uno perser JavaScript su misura (custom). Prima di aggiungere un diverso parser, considera se la complessità che si andrà ad aggiungere ne valga la pena.

Per usare un parser su misura (custom), installalo da npm (esempio: npm install --save-dev babel-eslint) ed esegui:

$ standard --parser babel-eslint

Oppure aggiungi questo al tuo package.json:

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

Se standard è installato globalmente (i.e. npm install standard --global), allora assicurati che anche babel-eslint sia installato globalmente, con npm install babel-eslint --global.

Prima di usare una variante di JavaScript, considera se l'aggiunta di complessità (ed energie richieste per permettere i nuovi sviluppatori di essere pronti) ne valga la pena.

standard supporta plugins ESLint. Utilizza uno di questi plugins per trasformare il codice in valido JavaScript prima che standard lo veda. Per usare un parser ad-hoc, installalo tramite npm ed esegui:

$ standard --plugin PLUGIN_NAME

Oppure aggiungi questo al tuo package.json:

{
  "standard": {
    "plugins": [ "PLUGIN_NAME" ]
  }
}

Per usare Flow, hai bisogno di usare babel-eslint come parser, Quindi, esegui npm install eslint-plugin-flowtype babel-eslint e dopo di che esegui:

$ standard --plugin flowtype --parser babel-eslint

Oppure aggiungi questo al tuo package.json:

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

Se standard è installato globalmente (es. npm install standard --global), allora assicurati che anche eslint-plugin-flowtype sia installato globalmente, con npm install eslint-plugin-flowtype --global.

Nota: plugin e plugins sono equivalenti.

Per supportare mocha nei tuoi file di test, aggiungi questo all'inizio dei tuoi file:

/* eslint-env mocha */

O esegui:

$ standard --env mocha

Dove mocha può essere anche jasmine, qunit, phantomjs, e così via. Per vedere l'intera lista, controlla la documentazione di ESlint su come specificare degli ambienti. Per una lista completa degli oggetti globali a disposizione degli ambienti, controlla la sezione globals del modulo npm.

Nota: env e envs sono equivalenti.

Aggiungi questo all'inizio del tuo file:

/* eslint-env serviceworker */

Per permettere a standard (anche per quando qualcun altro leggerà il tuo codice) di far sapere che self è un oggetto globale all'interno del codice del tuo web worker.

Per controllare codice all'interno di file di tipo Markdown, usa standard-markdown.

In alternativa, ci sono diversi plugin di ESLint per controllare il codice all'interno di Markdown, HTML e altri tipi di file:

Per controllare il codice dentro un file Markdown, usa il plugin ESLint:

$ npm install eslint-plugin-markdown

Dopodiche, per controllare codice JavaScript che compare dentro un blocco di codice, esegui:

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

Per controllare codice dentro file HTML, usa il plugin ESLint:

$ npm install eslint-plugin-html

Dopodiche, per controllare codice JavaScript che compare dentro i tag <script>, esegui:

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

Divertente!

#!/bin/sh 
#Assicurati che tutti i file javascript pronti per il commit passano lo standard code style 
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi

L'output all'interno della libreria è alquanto basilare, ma se ti piacciono le cose sfarzose, allora installa snazzy:

$ npm install snazzy

Ed esegui:

$ standard --verbose | snazzy

Ci sono anche standard-tap, standard-json, standard-reporter, e standard-summary.

Sì!

Esegue il lint sul parametro passato come input text. Il parametro opts è un oggetto con le seguenti opzioni:

{
  cwd: '',      // l'attuale cartella del tuo progetto (default: process.cwd()) 
  filename: '', // percorso del file al quale verrà eseguito il lint (opzionale, visto che alcuni plugin ne hanno bisogno) 
  fix: false,   // corregge gli errori automaticamente 
  globals: [],  // particolari variabili globali da dichiarare 
  plugins: [],  // particolari plugin eslint 
  envs: [],     // particolari eslint environments 
  parser: ''    // particolari parser JavaScript (es. babel-eslint) 
}

Ulteriori opzioni possono essere caricate usando package.json se si trova all'interno della cartella del tuo progetto.

Il parametro callback sarà chiamato con un Error ed un oggetto results.

L'oggetto results conterrà se seguenti proprietà:

var results = {
  results: [
    {
      filePath: '',
      messages: [
        { ruleId: '', message: '', line: 0, column: 0 }
      ],
      errorCount: 0,
      warningCount: 0,
      output: '' // codice sorgente fissato (accessibile solo con opzione {fix: true}) 
    }
  ],
  errorCount: 0,
  warningCount: 0
}

Versione sincrona di standard.lintText(). Se si verifica un errore, viene lanciata un'eccezione. Altrimenti viene ritornato l'oggetto results.

Esegue il lint sui files glob. È possibile passare un oggetto opts:

var opts = {
  ignore: [],   // file globs da ignorare (ha alcuni defaults) 
  cwd: '',      // l'attuale cartella del tuo progetto (default: process.cwd()) 
  fix: false,   // corregge gli errori automaticamente 
  globals: [],  // particolari variabili globali da dichiarare 
  plugins: [],  // particolari plugin eslint 
  envs: [],     // particolari eslint environments 
  parser: ''    // particolari parser JavaScript (es. babel-eslint) 
}

Il parametro callback sarà chiamato con un Error ed un oggetto results. (lo stesso di prima).

I collaboratori sono i benvenuti! Controlla le issue o le PR e crea la tua di PR se vuoi qualcosa che non vedi.

Vuoi chattare? Unisciti ai collaboratori su IRC nel canale #standard su freenode.

Eccoti importanti module che sono importanti nell'ecosistema di standard:

Ci sono anche molti plugin per l'editor di testo, una lista di npm packages che usano standard, una incredibile lista di packages nell'ecosistema di standard.

MIT. Copyright (c) Feross Aboukhadijeh.