JavaScript Standard Style

One JavaScript Style to Rule Them All

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


이 모듈은 다음과 같은 세 가지 방법으로 시간을 절약할 수 있습니다.

만드는 것의 대해 결정할 필요가 없습니다. .eslintrc, .jshintrc, .jscsrc 파일들을 관리할 필요가 없이 바로 가능합니다.

설치하는 방법입니다.

npm install standard --save-dev

더 나은 아이디어를 얻으려면 JavaScript Standard 스타일로 작성된 샘플 파일을 살펴보십시오. 또는 standard을 사용하는 수천 개의 프로젝트 중 하나를 확인하십시오!

JavaScript Standard Style을 사용하는 가장 쉬운 방법은 Node 명령 프로그램을 통해 전역으로 설치하는 것입니다. 터미널에서 다음 명령을 실행하세요.

$ npm install standard --global

또는 standard를 로컬에 설치하여 단일 프로젝트에서 사용할 수 있습니다.

$ npm install standard --save-dev

메모: 위 명령을 실행하려면 Node.jsnpm이 설치되어 있어야 합니다.

standard를 설치 한 후에 standard 프로그램을 사용할 수 있습니다. 가장 간단한 사용 사례는 현재 작업 디렉토리에있는 모든 JavaScript 파일의 스타일을 확인하는 것입니다.

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

You can optionally pass in a directory (or directories) using the glob pattern. Be sure to quote paths containing glob patterns so that they are expanded by standard instead of your shell: glob 패턴을 사용하여 디렉토리(또는 디렉토리들)를 선택적으로 전달할 수 있습니다. glob 패턴을 포함하는 경로를 인용 부호로 묶어 쉘 대신에 standard에 의해 확장되도록 할 수 있습니다.

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

메모 기본적으로standard**/*.js, **/*.jsx 패턴과 일치하는 모든 파일을 찾을 것입니다.

  1. package.json에 다음코드를 추가합니다.
{
  "name": "my-cool-package",
  "devDependencies": {
    "standard": "*"
  },
  "scripts": {
    "test": "standard && node my-tests.js"
  }
}
  1. npm test를 실행할 때 자동으로 스타일을 검사합니다.
$ npm test
Error: Use JavaScript Standard Style
  lib/torrent.js:950:11: Expected '===' and instead saw '=='.
  1. style 의견의 대해 절대로 풀 리퀘스트를 요청하지 마세요.

JavaScript Standard Style의 장점은 간단하다는 것입니다. 어느누구도 작업하는 모든 모듈/프로젝트에 대해 수백 줄 style의 구성 파일을 유지하려고하지 않습니다. 더 이상 바보같은 짓은 그만하세요.

이 모듈은 세가지의 방법으로 당신(또는 주변사람들)의 시간을 절약할 수 있습니다.

standard 스타일을 채택한다는 것은 개인적 스타일보다 코드 명확성과 커뮤니티 협업의 중요성을 우선으로 하는 것을 의미합니다. 이것은 프로젝트와 개발문화에 100% 타당하지 않을 수도 있지만, 오픈소스는 초보자들에게 적대적인 장소가 될 수 있습니다. 명확하고 자동화된 기여를 기대할수록 프로젝트가 더욱 건강해 집니다.

주변에 많은 사람들!

회사 이외에 많은 커뮤니티 회원은 여기에 나열하기에는 너무 많은 패키지들이 standard를 사용합니다.

또한 GitHub의 Clean Code Linter 쇼케이스에서도 볼 수 있습니다.

먼저, standard를 설치합니다. 그런 다음, 편집기에 적절한 플러그인을 설치하세요.

Package Control 을 사용하여, SublimeLinterSublimeLinter-contrib-standard 를 설치합니다.

저장시 자동포멧을 적용하려면 StandardFormat 을 설치하세요.

linter-js-standard 를 설치합니다.

저장시 자동포멧을 적용하려면 standard-formatter 를 설치합니다. 스니펫의 경우 standardjs-snippets 을 설치합니다.

vscode-standardjs 를 설치합니다. (자동포멧을 지원합니다.)

JS 스니펫의 경우 vscode-standardjs-snippets 을 설치합니다. React 스니펫의 경우 vscode-react-standard 를 설치합니다.

ale 를 설치합니다.

For automatic formatting on save, add these lines to .vimrc:

저장시 자동포멧을 적용하려면 해당 코드를 .vimrc에 추가하세요.

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

고려해야 할 대체 플러그인으로는 neomakesyntastic이 있으며, 둘 다 표준에 대한 지원이 내장되어 있습니다. (추가적으로 구성이 필요할 수도 있습니다)

Flycheck 를 설치하고 manual 을 확인하여 프로젝트에서 활성화하는 방법을 확인하십시오.

extension registry에서 "Standard Code Style" 을 검색하여 "Install"을 클릭하세요.

WebStrom은 standard가 직접적으로 IDE에서 사용가능다고 기본적인 지원에 관한 최근 발표 했습니다.

만약 수동으로 standard를 구성하려면 안내서를 따르십시오. 이것은 PhpStorm, IntelliJ, RubyMine 등 모든 JetBrains 제품에 적용됩니다.

네! 프로젝트에서 standard를 사용한다면, readme에 이 뱃지들 중 하나를 포함시켜 코드가 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)

안됩니다. standard의 전체적인 요점은 코드 스타일에 대한 bikeshedding을 피함으로써 시간을 절약하는 것입니다. 탭과 공백 등에 관해서는 온라인으로 많은 논쟁이 있기때문에 해결되지 않을 것입니다. 이러한 논쟁은 어떠한 것도 얻지 못하게합니다. 결국 뭔가를 골라야 한다입니다. 그것은 standard의 철학입니다. 이는 단지 뭔가를 선택하세요라는 의견입니다. 바라건대, 사용자들이 자신들의 의견을 방어하는 것에 대해 가치를 보게 되기를 바랍니다.

수백 개의 ESLint 규칙을 개별적으로 구성하려는 경우 eslint를 직접 eslint-config-standard와 함께 사용하여 변경 사항을 맨 위에 배치 할 수 있습니다.

팁 : 표준을 사용하고 계속 진행하십시오. 당신의 시간을 소비하고 있는 실질적인 문제를 해결하세요! :P

물론 표준이 아닙니다! 여기에 제시된 스타일은 공식 웹 표준 그룹과 관련이 없으므로 ECMA/standard이 아닌 standard/standard라고하는 이유입니다.

"standard"이라는 단어는 "web standard"이상의 의미를 가지고 있습니다 :-)

예를 들어,

예! standard --fix를 사용하면 자동으로 대부분의 문제를 자동으로 해결할 수 있습니다.

standard --fix는 최대의 편의를 위해 standard에 내장되어 있습니다. 대부분의 문제점은 고칠 수 있지만 일부 오류(오류 처리를 잊어 버리는 것)는 수동으로 해결해야합니다.

시간을 절약하기 위해 standard는 자동으로 수정할 수있는 문제를 발견하면 "Run standard --fix to automatically fix some problems" 메시지를 출력합니다.

특정 경로 (node_modules/, coverage/, vendor/, *.min.js, bundle.js, .git/와 같이 .으로 시작하는 파일/폴더)는 자동으로 무시됩니다.

프로젝트의 루트 .gitignore 파일에 있는 경로도 자동으로 무시됩니다.

때로는 추가 폴더 또는 특정 축소 파일을 무시해야합니다. 이를 수행하려면 package.jsonstandard.ignore 속성을 추가하십시오.

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

드문 경우이지만 규칙을 위반하고 standard에 의해 생성 된 경고를 숨길 필요가 있습니다.

JavaScript 표준 스타일은 ESLint를 사용하며 ESLint를 직접 사용한 경우 일반적으로 경고를 숨길 수 있습니다.

자세한 출력을 얻으려면 (무시할 특정 규칙 이름을 찾을 수 있도록) 다음을 실행하십시오.

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

특정 줄에서 모든 규칙 을 비활성화할 수 있습니다.

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

혹은, 특정 줄에서 "no-use-before-define" 규칙만 비활성화 할 수 있습니다.

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

"no-use-before-define" 규칙을 여러 줄에 적용할 수 있습니다.

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

일부 패키지 (예 : mocha)는 전역 개체 (가난한 형태!)에 기능 (예 : describe, it)을 지정합니다. 이 함수는 정의되지 않았거나 코드의 어느 곳에서든지 요구 될 수 있기 때문에 standard에서는 정의되지 않은 변수를 사용하고 있다고 경고합니다 (일반적으로 이 규칙은 오타를 잡는 데 유용합니다). 그러나 우리는 이 전역 변수들에 대해 이를 비활성화 하고자합니다.

standard (코드를 읽는 사람뿐만 아니라)에서 특정 변수가 코드에서 전역이라는 것을 알 수 있도록 파일의 맨 위에 추가하십시오.

/* global myVar1, myVar2 */

수백 개의 파일이 있다면 모든 파일에 주석을 추가하지 않는 것이 좋습니다. 이 경우 다음을 실행하십시오.

$ standard --global myVar1 --global myVar2

혹은 package.json에 다음코드를 추가하세요.

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

*노트: globalglobals는 같습니다.

standard는 제안 프로세스의 "단계 4"에있는 언어 기능 제안을 포함하여 최신 ECMAScript 기능인 ES8 (ES2017)을 지원합니다.

실험용 언어 기능을 지원하기 위해 standard는 맞춤 JavaScript 파서를 지정하는 것을 지원합니다. 커스텀 파서를 사용하기 전에 추가 된 복잡성이 그럴 가치가 있는지 고려하십시오.

$ standard --parser babel-eslint

혹은, package.json에 아래코드를 추가하세요.

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

standard'가 전역으로 설치되면 (즉,npm install standard --global),babel-eslintnpm install babel-eslint --global`과 함께 설치하십시오.

커스텀 JS 언어 변형을 사용하기 전에 추가된 복잡성 (그리고 새로운 기여자를 최신으로 만드는데 필요한 노력)이 그만한 가치가 있는지 고려하십시오.

standard는 ESLint 플러그인을 지원합니다. standard 중 하나를 보기 전에 코드를 유효한 JavaScript로 변환하려면 이 중 하나를 사용하십시오. 맞춤 구문 분석기를 사용하려면 npm에서 설치하고 다음을 실행하십시오.

$ standard --plugin 플러그인_이름

아니면, package.json에 아래 코드를 추가하세요.

{
  "standard": {
    "plugins": [ "플러그인_이름" ]
  }
}

Flow를 사용하려면 babel-eslint를 파서로 사용해야합니다. 따라서 npm install eslint-plugin-flowtype babel-eslint를 수행한 후에, 다음을 실행하십시오.

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

아니면, package.json에 아래 코드를 추가하세요.

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

standard가 전역으로 설치된 경우 (즉, npm install standard --global) npm install-eslint-plugin-flowtype --global을 사용하여 eslint-plugin-flowtype을 전역으로 설치해야합니다.

참고 : 플러그인 및 플러그인은 동일합니다.

테스트 파일에서 mocha를 지원하려면 테스트 파일의 시작 부분에 다음을 추가하십시오.

/* eslint-env mocha */

혹은 다음을 실행하세요.

$ standard --env mocha

mochajasmine, qunit, phantomjs 중 하나가 될 수 있습니다. 전체 목록을 보려면 ESLint의 specifying environments(스펙문서)를 확인하십시오. 이러한 환경에서 사용할 수있는 전역의 목록을 보려면 globals npm 모듈을 확인하십시오.

참고 : envenvs는 동일합니다.

적용하려는 파일 상단에 아래 주석코드를 추가하세요.

/* eslint-env serviceworker */

이것은 standard (자신의 코드를 읽는 사람뿐만 아니라)이 web worker 코드에서 자신이 전역(global)이라는 것을 알 수 있게 해줍니다.

Markdown 파일 내의 코드를 확인하려면 standard-markdown을 사용하십시오.

또는 Markdown, HTML 및 기타 여러 유형의 언어 파일에서 코드를 확인할 수있는 ESLint 플러그인이 있습니다.

Markdown 파일 내의 코드를 확인하려면 ESLint 플러그인을 사용하십시오.

$ npm install eslint-plugin-markdown

그런 다음, 코드 블록 안에있는 JS를 확인하려면 다음을 실행하십시오.

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

HTML 파일 내부의 코드를 확인하려면 ESLint 플러그인을 사용하십시오.

$ npm install eslint-plugin-html

그런 다음, <script>태그 안에있는 JS를 확인하려면 다음을 실행하십시오.

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

재미있는 질문이네요!

#!/bin/sh 
# 커밋을 위해 준비된 모든 자바 스크립트 파일이 표준 코드 스타일을 통과하는지 확인합니다. 
git diff --name-only --cached --relative | grep '\.jsx\?$' | xargs standard
if [ $? -ne 0 ]; then exit 1; fi

내장 된 출력물은 간단하고 간단하지만 반짝이는 물건을 원한다면 snazzy 설치하십시오.

$ npm install snazzy

그리고 아래 명령어를 실행합니다.

$ standard --verbose | snazzy

standard-tap, standard-json, standard-reporter, standard-summary도 있습니다..

네!

린트에 제공할 소스 text를 준비합니다. opts 객체를 추가할 수 있습니다.

{
  cwd: '',      // 현재 작업 디렉토리 (기본: process.cwd()) 
  filename: '', // 린트 텍스트를 포함하는 파일의 경로 (선택, 일부 eslint 플러그인이 필요함) 
  fix: false,   // 자동 문제 해결 
  globals: [],  // 선언할 커스텀 글로벌 변수 
  plugins: [],  // 커스텀 eslint 플러그인 
  envs: [],     // 커스텀 eslint 환경 
  parser: ''    // 커스텀 js 파서  (예: babel-eslint) 
}

package.json가 현재 작업 디렉토리에서 발견되면 추가옵션을 로드 할 수 있습니다.

콜백(callback)Errorresults객체와 함께 호출 될 것입니다.

results객체는 다음과 같은 속성을 포함합니다.

var results = {
  results: [
    {
      filePath: '',
      messages: [
        { ruleId: '', message: '', line: 0, column: 0 }
      ],
      errorCount: 0,
      warningCount: 0,
      output: '' // 고정 소스 코드 ({fix : true} 옵션과 함께 제공) 
    }
  ],
  errorCount: 0,
  warningCount: 0
}

standard.lintText()의 동기화 버전. 오류가 발생하면 예외가 발생합니다. 그렇지 않으면 results객체가 반환됩니다.

제공된 'files' 덩어리를 린트에 적용할 수 있습니다. opts 객체를 추가할 수 있습니다.

var opts = {
  ignore: [],   // 파일뭉치를 무시합니다. (기본적인 무시파일들이 포함되어 있습니다) 
  cwd: '',      // 현재 작업 디렉토리 (기본: process.cwd()) 
  fix: false,   // 자동 문제 해결 
  globals: [],  // 선언할 글로벌 변수 
  plugins: [],  // eslint 플러그인 
  envs: [],     // eslint 환경 
  parser: ''    // js 파서 (예: babel-eslint) 
}

callbackErrorresults객체로 호출됩니다. (위와 같습니다)

기여를 환영합니다! issuesPRs를 확인하고 거기에 보이지 않는 것을 원한다면 직접 만들어주세요.

채팅을 원하시나요? freenode의 #standard 채널에서 IRC의 참여자와 함께하세요.

다음은 standard 생태계의 중요한 패키지입니다.

또한 많은 에디터 플러그인, standard를 사용하는 npm 패키지 목록, standard 에코 시스템의 멋진 패키지 목록 이 있습니다.

MIT. Copyright (c) Feross Aboukhadijeh.