JavaScript Standard Style
English • Español (Latinoamérica) • Italiano (Italian) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin)
](https://www.npmjs.com) | [
](https://github.com) | [
](https://opbeat.com) | [
](http://www.nearform.com) | [
](https://www.brave.com) |
|---|---|---|---|---|
| [
](https://zeit.co) | [
](https://www.zendesk.com) | [
](https://www.mongodb.com) | [
](https://www.typeform.com) | [
](https://gds.blog.gov.uk) |
|---|---|---|---|---|
[
](http://expressjs.com) | [
](https://webtorrent.io) | [
](https://ipfs.io) | [
](https://datproject.org) | [
](https://bitcoinjs.org) |
|---|---|---|---|---|
[
](https://atom.io) | [
](http://electron.atom.io) | [
](https://voltra.co) | [
](https://www.treasuredata.com) | [
](https://clevertech.biz) |
|---|---|---|---|---|
[
](https://www.apstudynotes.org) | [
](https://www.optiopay.com) | [
](https://www.jlrtechincubator.com/jlrti/) | [
](https://www.bustle.com) | [
](https://www.zentrick.com) |
|---|---|---|---|---|
[
](https://nodesource.com) | [
](https://greenkeeper.io) | [
](https://karma-runner.github.io) | [
](https://www.taser.com) | [
](https://www.neo4j.com) |
|---|---|---|---|---|
Oltre alle aziende, anche molti membri della comunità usano `standard` su pacchetti che sono [troppo numerosi](https://raw.githubusercontent.com/feross/standard-packages/master/all.json) da mostrare qui.
`standard` è inoltre il miglior linter favorito dal caso d'uso dalla GitHub [Clean Code Linter](https://github.com/showcases/clean-code-linters).
## Ci sono dei plugin per gli editor di testo?
Primo, installa `standard`. Dopo di che installa il plugin più appropriato per il tuo editor:
### Sublime Text
Usano **[Package Control][sublime-1]**, installa **[SublimeLinter][sublime-2]** e
**[SublimeLinter-contrib-standard][sublime-3]**.
Per la formattazione automatica durante il salvataggio, installa **[StandardFormat][sublime-4]**.
[sublime-1]: https://packagecontrol.io/
[sublime-2]: http://www.sublimelinter.com/en/latest/
[sublime-3]: https://packagecontrol.io/packages/SublimeLinter-contrib-standard
[sublime-4]: https://packagecontrol.io/packages/StandardFormat
### Atom
Installa **[linter-js-standard][atom-1]**.
In alternativa, puoi installare **[linter-js-standard-engine][atom-4]**. 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][atom-5]**.
Per la formattazione automatica, installa **[standard-formatter][atom-2]**. Per aiuti (snippets),
installa **[standardjs-snippets][atom-3]**.
[atom-1]: https://atom.io/packages/linter-js-standard
[atom-2]: https://atom.io/packages/standard-formatter
[atom-3]: https://atom.io/packages/standardjs-snippets
[atom-4]: https://atom.io/packages/linter-js-standard-engine
[atom-5]: https://github.com/Flet/standard-engine
### Visual Studio Code
Installa **[vscode-standardjs][vscode-1]**. (Include supporto per la formattazione automatica.)
Per JS snippets, installa: **[vscode-standardjs-snippets][vscode-2]**. Per ReactJS snippets, installa **[vscode-react-standard][vscode-3]**.
[vscode-1]: https://marketplace.visualstudio.com/items/chenxsan.vscode-standardjs
[vscode-2]: https://marketplace.visualstudio.com/items?itemName=capaj.vscode-standardjs-snippets
[vscode-3]: https://marketplace.visualstudio.com/items/TimonVS.ReactSnippetsStandard
### Vim
Installa **[ale][vim-1]**.
Per la formattazione automatica al salvataggio, aggiungi quelle linee a `.vimrc`:
```vim
autocmd bufwritepost *.js silent !standard --fix %
set autoread
```
Pacchetti alternativi che possono essere inclusi sono [neomake][vim-2] e [syntastic][vim-3], entrambi hanno all'interno il supporto per `standard` (configurazione potrebbe essere necessaria).
[vim-1]: https://github.com/w0rp/ale
[vim-2]: https://github.com/neomake/neomake
[vim-3]: https://github.com/vim-syntastic/syntastic
### Emacs
Installa **[Flycheck][emacs-1]** e controlla **[manual][emacs-2]** per imparare come abilitarlo all'interno del tuo progetto.
[emacs-1]: http://www.flycheck.org
[emacs-2]: http://www.flycheck.org/en/latest/user/installation.html
### Brackets
Cerca l'estenzione di registro per **["Standard Code Style"][brackets-1]** and clicca "Install".
[brackets-1]: https://github.com/ishamf/brackets-standard/
### WebStorm (PhpStorm, IntelliJ, RubyMine, JetBrains, etc.)
WebStorm [ha annunciato recentemente supporto nativo](https://blog.jetbrains.com/webstorm/2017/01/webstorm-2017-1-eap-171-2272/)
per `standard` direttamente nell'IDE.
Se preferisci configurare `standard` manualmente, [segui questa guida][webstorm-1]. 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][webstorm-1]. This applies to all JetBrains products, including PhpStorm, IntelliJ, RubyMine, etc.
[webstorm-1]: docs/webstorm.md
## Esiste un banner?
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.
[](https://github.com/standard/standard)
```md
[](https://github.com/standard/standard)
```
[](https://standardjs.com)
```md
[](https://standardjs.com)
```
## Non sono d'accordo con la regola X, posso cambiarla?
No. Il punto essenziale di `standard` è di aiutarti a salvare tempo evitando [bikeshedding][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](https://github.com/standard/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
[bikeshedding]: https://www.freebsd.org/doc/en/books/faq/misc.html#bikeshed-painting
## Ma questo non è un vero web standard!
Ovvio che no! Lo stile presentato qui non è affiliato con nessuno degli gruppi standard web, ecco perchè questo repository si chiama `feross/standard` e non `ECMA/standard`.
La parola "standard" signica più di un "web standard" :-) Per esempio:
- Questo module aiuta a tenere il codice vicino ad uno *standard di qualità*
- Questo module assicura che nuovi contribtori seguano gli *stili standard*
## Esiste un formattatore automatico?
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.
## Come posso ignorare dei file?
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`:
```json
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
```
## Come posso nascondere un determinato avviso?
In rari casi, avarai la necessità di rompere le regole e nascondere l'avviso generato da `standard`.
JavaScript Standard Style usa [ESLint](http://eslint.org/) 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:
```bash
$ 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:
```js
file = 'So cosa sto facendo' // eslint-disable-line
```
O, disabilita **solo** la regola `"no-use-before-define"`:
```js
file = 'So cosa sto facendo' // eslint-disable-line no-use-before-define
```
O, disabilita la regola `"no-use-before-define"` per **più righe**:
```js
/* 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 */
```
## Utilizzo una libreria che inquina il namespace globale. Come posso prevenire errori del tipo "variable is not defined"?
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:
```js
/* global myVar1, myVar2 */
```
Se hai centiaia di file, sarebbe più conveniente evitare di aggiungere commenti su ogni file. In questo caso, esegui:
```bash
$ standard --global myVar1 --global myVar2
```
Oppure aggiungi questo al tuo `package.json`:
```json
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
```
*Nota: `global` e `globals` sono equivalenti.*
## Come posso usare funzionalità sperimentali di JavaScript (ES Next)?
`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:
```bash
$ standard --parser babel-eslint
```
Oppure aggiungi questo al tuo `package.json`:
```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`.
## Posso usare varianti di JavaScript come Flow?
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:
```bash
$ standard --plugin PLUGIN_NAME
```
Oppure aggiungi questo al tuo `package.json`:
```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:
```bash
$ standard --plugin flowtype --parser babel-eslint
```
Oppure aggiungi questo al tuo `package.json`:
```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.*
## Riguardo Mocha, Jasmine, QUnit, ecc.?
Per supportare mocha nei tuoi file di test, aggiungi questo all'inizio dei tuoi file:
```js
/* eslint-env mocha */
```
O esegui:
```bash
$ 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](http://eslint.org/docs/user-guide/configuring.html#specifying-environments). Per una lista completa degli oggetti globali a disposizione degli ambienti, controlla la sezione
[globals](https://github.com/sindresorhus/globals/blob/master/globals.json) del modulo npm.
*Nota: `env` e `envs` sono equivalenti.*
## Riguardo Web Workers?
Aggiungi questo all'inizio del tuo file:
```js
/* 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.
## Posso controllare codice dentro file di tipo Markdown o HTML?
Per controllare codice all'interno di file di tipo Markdown, usa [`standard-markdown`](https://www.npmjs.com/package/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:
```bash
$ npm install eslint-plugin-markdown
```
Dopodiche, per controllare codice JavaScript che compare dentro un blocco di codice, esegui:
```bash
$ standard --plugin markdown '**/*.md'
```
Per controllare codice dentro file HTML, usa il plugin ESLint:
```bash
$ npm install eslint-plugin-html
```
Dopodiche, per controllare codice JavaScript che compare dentro i tag `