English • Español (Latinoamérica) • Français • Italiano (Italian) • 日本語 (Japanese) • 한국어 (Korean) • Português (Brasil) • 简体中文 (Simplified Chinese) • 繁體中文 (Taiwanese Mandarin)
Ce module vous laisse gagner du temps de trois façons:
- Pas de configuration. La façon la plus facile d'assurer un style consistant dans vos projets.
- Formatte le code automatiquement. Exécutez
standard --fix
et dites au revoir aux irrégularités dans votre code. - Identifiez en avance les erreurs et problèmes de styles. Gagnez un temps précieux de revision du code en eliminant les échanges entre le contributeur et le réviseur.
Pas de decisions à prendre. Pas de fichiers .eslintrc
, .jshintrc
, ou .jscsrc
à gérer.
Installez avec:
npm install standard --save-dev
- 2 espaces – pour l'indentation
- Apostrophes (') pour le texte – à part pour éviter un caractère d'échappement
- Pas de variables non-utilisées
- Pas de point virgule – Tout va bien. Vraiment!
- Espace après les mots clés
if (condition) { ... }
- Espace après les noms de fonction
function name (arg) { ... }
- Utilisez toujours
===
au lieu de==
– maisobj == null
est autorisé pour vérifiernull || undefined
. - Gérez toujours le paramètre de fonction
err
de node.js - Déclarez les globales de navigateur avec le commentaire
/* global */
en haut du fichier- Prévient l'utilisation accidentelle de globales comme
open
,length
,event
, etname
. - Exemple:
/* global alert, prompt */
- Les exceptions sont:
window
,document
, etnavigator
- Prévient l'utilisation accidentelle de globales comme
- Et plus – donnes
standard
une chance!
Pour avoir une meilleure idée, jetez un coup d'oeil à
un exemple écrit
en JavaScript Standard Style. Ou, jetez un coup d'oeil à un des
milliers de projets
qui utilisent standard
!
- Démarrage rapide
- FAQ
- Pourquoi devrais-je utiliser le JavaScript Standard Style?
- Qui utilise le JavaScript Standard Style?
- Il y a-t-il des plugins pour les éditeurs de texte?
- Il y a-t-il un badge readme?
- Je ne suis pas d'accord avec la règle X, pouvez-vous la changer?
- Ce n'est pas un vrai standard web!
- Y a-t-il un formateur automatique?
- Comment ignorer des fichiers?
- Comment cacher certains avertissements?
- J'utilise une bibliothèque logicielle qui pollue l'espace de noms global. Comment puis-je éviter les erreurs "variable is not defined"?
- Comment puis-je utiliser les fonctionalités expérimentales de JavaScript (ES Next)?
- Puis-je utiliser une variation du language JavaScript, comme Flow ou TypeScript?
- Et Mocha, Jasmine, QUnit, etc?
- Et les Web Workers?
- Puis-je vérifier le code dans les fichiers Markdown ou HTML?
- Il y a-t-il un Git
pre-commit
? - Comment puis-je produire un resultat coloré et joli?
- Il y a-t-il une API Node.js?
- Comment puis-je contribuer à
standard
?
- Licence
La façon la plus facile d'utiliser le JavaScript Standard Style est de l'installer globalement comme un programme Node de ligne de commande. Exécutez la commande qui suit dans le Terminal:
$ npm install standard --global
Ou, vous pouvez installer standard
localement, pour l'utiliser dans un seul projet:
$ npm install standard --save-dev
Note: Pour executer les commandes précédentes, Node.js et npm doivent être installés.
Apres avoir installé standard
, vous devriez pouvoir l'utiliser. Le cas le plus facile serait de verifier le style de tous les fichiers JavaScrtipt dans le dossier actuellement utilisé:
$ standard
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
Vous pouvez passer en option un dossier (ou dossiers) en utilisant la structure glob. Soyez surs d'entourer les chemins de fichier qui contiennent des structures glob avec des guillemets pour qu'ils soient interprétés par standard
et pas votre shell:
$ standard "src/util/**/*.js" "test/**/*.js"
Note: par default standard
va chercher tous les fichiers qui correspondent à:
**/*.js
, **/*.jsx
.
- Ajoutez le au fichier
package.json
{
"name": "my-cool-package",
"devDependencies": {
"standard": "*"
},
"scripts": {
"test": "standard && node my-tests.js"
}
}
- Le style est vérifié automatiquement quand vous executez
npm test
$ npm test
Error: Use JavaScript Standard Style
lib/torrent.js:950:11: Expected '===' and instead saw '=='.
- Ne donnez plus jamais de feedback dans une PR!
La beauté du JavaScript Standard Style est dans sa simplicité. Personne ne veut maintenir des fichiers de configuration de style de plusieurs centaines de lignes pour chaque module/projet sur lesquels vous travaillez!
Ce module vous laisse gagner du temps de trois façons:
- Pas de configuration. La façon la plus facile d'assurer un style consistant dans vos projets.
- Formatte le code automatiquement. Exécutez
standard --fix
et dites au revoir aux irregularités dans votre code. - Identifiez en avance les erreurs et problèmes de styles. Gagnez un temps precieux de revision du code en éliminant les échanges entre le contributeur et le réviseur.
Adopter le style standard
c'est mettre l'importance de la clarité du code et des conventions de la communauté avant le style personel. Ça n'a peut-être pas de sens pour 100% des projets et cultures de développement, cependant, open-source peut être un environement hostile pour les jeunes développeurs. Mettre en place des attentes claires et automatisées pour les contributeurs permet un projet plus sain.
Pour plus d'information, jetez un oeil a la présentation "Write Perfect Code with Standard and
ESLint". Dans cette présentation, vous allez apprendre sur le linting, quand utiliser standard
contre eslint
, et comment prettier
compare à standard
.
Beaucoup de monde!
Your logo here | Your logo here | Your logo here |
---|
En plus de ces entreprises, beaucoup de membres de la communauté utilisent standard
sur des projets qui sont trop nombreux
pour les lister ici.
standard
est aussi le top linteur sur le showcase
Clean Code linter de Github.
D'abord, installez standard
. Après, installez le correct plugin pour votre éditeur:
En utilisant Package Control, installez Sublimelinter et Sublimelinter-contrib-standard.
Pour le formatage automatique quand vous sauvegardez, installez StandardFormat.
Installez linter-js-standard.
Autrement, vous pouvez installer linter-js-standard-engine. Au lieu de bundler une version de standard
, il va automatiquement utiliser la version installée dans le project actuel. Il marchera aussi tout de suite avec d'autres linteurs basés sur standard-engine.
Pour un formatage automatique, installez standard-formatter. Pour des extraits, installez standardjs-snippets.
Installez vscode-standardjs. (Cela inclus le support pour le formatage automatique.)
Pour des extraits JS, installez: vscode-standardjs-snippets. Pour des extraits React, installez vscode-react-standard.
Installez ale. Et ajoutez ces lignes dans votre fichier .vimrc
.
let g:ale_linters = {
\ 'javascript': ['standard'],
\}
Cela definit standard comme votre seul linteur pour les fichiers javascript et donc previent les conflits avec eslint.
Pour le formatage automatique quand vous sauvegardez, ajoutez ces lines à .vimrc
:
autocmd bufwritepost *.js silent !standard --fix %
set autoread
Les plugins alternatifs à considérer incluent neomake et syntastic, les deux ont un support integré pour standard
(une configuration est peut-être nécessaire).
Installez Flycheck et jetez un oeil au manuel pour apprendre à l'utiliser dans vos projets.
Cherchez les extensions pour "Standard Code Style" et cliquez "Install".
WebStorm à récemment annouce le support natif
pour standard
directement dans l'IDE.
Si vous préférez toujours configurer standard
manuellement, suivez ce guide. Cela s'applique à tous les produits JetBrains, inclus PhpStorm, IntelliJ, RubyMine, etc.
Oui! Si vouz utilisez standard
dans votre projet, vous pouvez inclure un de ces badges dans votre readme pour laisser les gens savoir que votre code utilise le style standard.
[![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)
Non. Le but de standard
est de gagner du temps en evitant
bikeshedding à propos du style de code. Il y a plein de débats en ligne à propos des tabs vs. espaces, etc. qui ne seront jamais résolus. Ces débats sont juste distractifs et empèchent de faire avancer les choses. A la fin de la journée, vouz devez faire un choix et c'est toute la philosophie derrière standard
-- c'est juste un tas d'opinions pour 'faire un choix'. J'espère que les utilisateurs voient la valeur au lieu de défendre leurs propres opinions.
Si vous voulez vraiment configurer des centaines de règles ESLint vous-mêmes, vous pouvez toujours utiliser eslint
directement avec
eslint-config-standard pour ajouter vos changement au-dessus.
standard-eject
peut vous aider a changer de standard
à eslint
et eslint-config-standard
.
Astuce pro: Utilisez juste standard
et passez à autre chose. Vous pourriez passer votre temps a résoudre de vrais problèmes! :P
Bien sur que non! Le style présenté ici n'est pas affilié à aucun groupe de standards web, ce pourquoi ce repo est appelé standard/standard
et pas
ECMA/standard
.
Le mot "standard" a plus de sens que juste "web standard" :-) Par exemple:
- Ce module aide à garder notre code à un certain standard de qualité.
- Ce module assure que les nouveaux contributeurs suivent les standards de style.
Oui! Vous pouvez utiliser standard --fix
pour résoudre la plupart des problèmes automatiquement.
standard --fix
fait parti de standard
pour un confort maximal. La plupart des problèmes peuvent être résolus, mais quelques erreurs (comme oublier de gérer les erreurs) doivent être résolues manuellement.
Pour gagner du temps, standard
produit le message "Run standard --fix to automatically fix some problems
" quand il détecte des problèmes qui peuvent être résolus automatiquement.
Quelques chemins de fichiers (node_modules/
, coverage/
, vendor/
, *.min.js
, bundle.js
,
et fichiers/dossiers qui commencent avec .
comme .git/
) sont automatiquement ignorés.
Les chemins de fichiers dans le fichier .gitignore
sont aussi automatiquement ignorés.
Parfois, vous devez ignorer d'autres dossiers ou des fichiers spécifiques. Pour cela, ajoutez une propriéte standard.ignore
au fichier package.json
:
"standard": {
"ignore": [
"**/out/",
"/lib/select2/",
"/lib/ckeditor/",
"tmp.js"
]
}
Dans de rares cas, vous allez devoir enfreindre une règle et cacher l'avertissement généré par standard
.
JavaScript Standard Style utilise ESLint et vouz pouvez cacher les avertissements comme vous le feriez avec ESLint.
Pour obtenir un resultat plus verbeux (pour que vous puissiez trouver la règle particulière à ignorer), éxécutez:
$ standard --verbose
Error: Use JavaScript Standard Style
routes/error.js:20:36: 'file' was used before it was defined. (no-use-before-define)
Désactivez toutes les règles pour une ligne particulière:
file = 'I know what I am doing' // eslint-disable-line
Ou, désactivez seulement la règle "no-use-before-define"
:
file = 'I know what I am doing' // eslint-disable-line no-use-before-define
Ou, désactivez la règle "no-use-before-define"
pour plusieurs lignes:
/* 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 */
J'utilise une bibliothèque logicielle qui pollue l'espace de noms global. Comment puis-je éviter les erreurs "variable is not defined"?
Quelques modules (ex. mocha
) mettent leurs fonctions (ex. describe
, it
) sur l'objet global. Puisque ces fonctions ne sont pas définies ou requises (require
'd) nulle part dans votre code, standard
vous avertira que vous utilisez une variable qui n'est pas définie (normalement, cette règle est très utile pour capter les fautes d'orthographe!). Mais nous voulons les désactiver pour les variables globales.
Pour informer standard
(et les personnes qui lisent votre code) que certaines variables sont globales dans votre code, ajoutez ça au debut de votre fichier:
/* global myVar1, myVar2 */
Si vous avez des centaines de fichiers, il serait peut être désirable d'éviter d'ajouter des commentaires à chaque fichier. Dans ce cas, éxécutez:
$ standard --global myVar1 --global myVar2
Ou, ajoutez ça au fichier package.json
:
{
"standard": {
"globals": [ "myVar1", "myVar2" ]
}
}
Note: global
et globals
sont équivalents.
standard
supporte les dernières fonctionalités d'ECMAScript, ES8 (ES2017), comprenant les propositions qui sont à l'"étape 4" du processus de proposition.
Pour supporter les fonctionalités expérimentales, standard
supporte la spécification d'un parseur JavaScript personalisé. Avant d'utiliser un parseur personalisé, il faut considérer si la compléxité ajoutée vaut le coup.
Pour utiliser un autre parseur, installez-le d'abord avec npm:
npm install babel-eslint --save-dev
Ensuite éxécutez:
$ standard --parser babel-eslint
Ou, ajoutez ça au package.json
:
{
"standard": {
"parser": "babel-eslint"
}
}
Si standard
est installé globalement (npm install standard --global
), soyez surs d'installer babel-eslint
globalement aussi, avec
npm install babel-eslint --global
.
standard
supporte les dernières fonctionalités d'ECMAScript. Cependant, Flow et TypeScript ajoutent une nouvelle syntaxe au langage, alors ils ne sont pas supportés par defaut.
Pour supporter les variations, standard
supporte la spécification d'un parseur JavaScript personnalisé en même temps qu'un plugin ESLint pour manager la syntaxe modifiée. Avant d'utiliser une variation, demandez-vous si la complexitée ajoutée vaut le coup.
Pour utiliser Flow, vous allez devoir éxécuter standard
avec babel-eslint
comme parseur et
eslint-plugin-flowtype
comme plugin.
npm install babel-eslint eslint-plugin-flowtype --save-dev
Ensuite éxécutez:
$ standard --parser babel-eslint --plugin flowtype
Ou, ajoutez ça au package.json
:
{
"standard": {
"parser": "babel-eslint",
"plugins": [ "flowtype" ]
}
}
Note: plugin
et plugins
sont équivalents.
Si standard
est installé globalement (npm install standard --global
), soyez sur d'installer babel-eslint
et eslint-plugin-flowtype
globalement aussi, avec
npm install babel-eslint eslint-plugin-flowtype --global
.
Pour utiliser TypeScript, vous allez devoir éxécuter standard
avec @typescript-eslint/parser
comme parseur,
eslint-plugin-typescript
comme plugin, et dire à standard de linter les fichiers *.ts
(puisqu'il ne le fait pas par défaut).
npm install @typescript-eslint/parser eslint-plugin-typescript --save-dev
Ensuite éxécutez:
$ npm install @typescript-eslint/parser @typescript-eslint/eslint-plugin --save-dev
Ou, ajoutez ça au package.json
:
{
"standard": {
"parser": "@typescript-eslint/parser",
"plugins": [ "@typescript-eslint/eslint-plugin" ]
}
}
Avec ça dans le package.json
, vous pouvez éxécuter:
standard *.ts
Si standard
est installé globalement (npm install standard --global
), soyez sur d'installer @typescript-eslint/parser
et eslint-plugin-typescript
globalement aussi,
avec npm install @typescript-eslint/parser eslint-plugin-typescript --global
.
Pour supporter Mocha dans les fichiers de test, ajoutez ça en haut des fichiers de test:
/* eslint-env mocha */
Ou, éxécutez:
$ standard --env mocha
Dans cette commande, mocha
peut être jasmine
, qunit
, phantomjs
, etc. Pour voir la liste complète, jetez un coup d'oeil a la documentation d'ESLint specifiant les environements. Pour une liste détaillant quelles globales sont disponibles pour ces environements, jetez un coup d'oeil au module npm
globals.
Note: env
et envs
sont équivalents.
Ajoutez ça en haut du fichier web worker:
/* eslint-env worker */
Cela indique à standard
(et aux personnes lisant le code) que self
est une global dans le code du web worker.
Pour les Service workers, ajoutez ça:
/* eslint-env serviceworker */
Pour vérifier le code dans les fichiers Markdown, utilisez standard-markdown
.
Autrement, il y a des plugins ESLint qui peuvent vérifier le code dans les fichiers Markdown, HTML et plein d'autres genres de fichiers:
Pour verifier le code dans les fichiers Markdown, utilisez un plugin ESLint:
$ npm install eslint-plugin-markdown
Ensuite, pour vérifier le JS à l'interieur des blocs de code, éxécutez:
$ standard --plugin markdown '**/*.md'
Pour verifier le code à l'interieur des fichiers HTML, utilisez un plugin ESLint:
$ npm install eslint-plugin-html
Ensuite, pour vérifier le code JS qui apparait dans les <script>
, éxécutez:
$ standard --plugin html '**/*.html'
#!/bin/bash
# Assurez-vous que tous les fichiers JavaScript prets à être commis passent les standards de style de code
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
Le resultat integré est simple et direct, mais si vous aimez les trucs sophistiqués, installez snazzy:
$ npm install snazzy
Et éxécutez:
$ standard --verbose | snazzy
Il y a aussi standard-tap, standard-json, standard-reporter, et standard-summary.
Oui!
Lint le texte fourni. Un objet opts
peut être fourni:
{
cwd: '', // current working directory (default: process.cwd())
filename: '', // path of the file containing the text being linted (optional, though some eslint plugins require it)
fix: false, // automatically fix problems
globals: [], // custom global variables to declare
plugins: [], // custom eslint plugins
envs: [], // custom eslint environment
parser: '' // custom js parser (e.g. babel-eslint)
}
D'autres options peuvent être utilisées à partir d'un fichier package.json
s'il est trouvé dans le dossier courant.
Le callback
sera appelé avec un objet Error
et results
.
L'objet results
aura les propriétes suivantes:
var 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
}
C'est la version synchrone de standard.lintText()
. Si une erreur arrive, une exception est jetée. Autrement, un objet results
est retourné.
Lint les fichiers qui correspondent aux globs fournis. Un objet opts
peut être fourni:
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)
}
Le callback
sera appelé avec un objet Error
et results
(comme au-dessus).
Les contributions sont bienvenues! Jetez un coup d'oeil aux issues et aux PRs, et faites la votre si vous voulez quelque chose que vous ne trouvez pas la.
Envie de discuter? Joignez les contributeurs sur IRC dans la chaine #standard
sur freenode.
Voici quelques modules importants dans l'ecosystème standard
:
- standard - ce repo
- standard-engine - le moteur cli pour les règles eslint
- eslint-config-standard - les règles eslint pour standard
- eslint-config-standard-jsx - les règles eslint pour standard (JSX)
- eslint-plugin-standard - règles eslint customisées pour standard (ne fait pas partie de eslint core)
- eslint - le linteur qui alimente standard
- snazzy - résultats de standard plus jolis dans le terminal
- standard-www - le code pour https://standardjs.com
- semistandard - standard, avec point-virgules (si nécessaire)
Il y a aussi plein de plugins pour editeur, une liste de
modules npm qui utilisent standard
,
et une super liste de
modules dans l'ecosystème standard
.
MIT. Copyright (c) Feross Aboukhadijeh.