From 2a5f1a2e072e9a17e2eeb5d63f1f8af917e877cd Mon Sep 17 00:00:00 2001 From: molee1905 Date: Sat, 30 Apr 2016 04:21:04 +0800 Subject: [PATCH] Docs:fix some typos and wrong whitespace --- docs/about/index.md | 6 +-- docs/developer-guide/architecture.md | 10 ++--- docs/developer-guide/working-with-rules.md | 2 +- docs/issue/autofixing.md | 46 +++++++++++----------- docs/rules/block-scoped-var.md | 5 +-- docs/rules/comma-dangle.md | 2 +- docs/rules/index.md | 4 +- docs/rules/no-control-regex.md | 2 +- docs/rules/no-duplicate-case.md | 4 +- docs/rules/no-undef.md | 4 +- docs/user-guide/command-line-interface.md | 6 +-- docs/user-guide/configuring.md | 30 +++++++------- 12 files changed, 61 insertions(+), 60 deletions(-) diff --git a/docs/about/index.md b/docs/about/index.md index 0f941914b1..fb587af35c 100644 --- a/docs/about/index.md +++ b/docs/about/index.md @@ -23,7 +23,7 @@ ESLint 的初衷是为了让程序员可以创建自己的检测规则。ESLint ESLint is written using Node.js to provide a fast runtime environment and easy installation via [npm][]. -ESLint使用Node.js编写，这样既可以有一个快速的运行环境的同时也便于安装。 +ESLint 使用 Node.js 编写，这样既可以有一个快速的运行环境的同时也便于安装。 [linting]: http://en.wikipedia.org/wiki/Lint_(software) [npm]: http://npmjs.org/ @@ -35,9 +35,9 @@ Everything is pluggable: 所有都是可拔插的 * Rule API is used both by bundled and custom rules -* 内置规则和自定义规则共用一套规则API +* 内置规则和自定义规则共用一套规则 API * Formatter API is used both by bundled and custom formatters -* 内置的格式化方法和自定义的格式化方法共用一套格式化API +* 内置的格式化方法和自定义的格式化方法共用一套格式化 API * Additional rules and formatters can be specified at runtime * 额外的规则和格式化方法能够在运行时指定 * Rules and formatters don't have to be bundled to be used diff --git a/docs/developer-guide/architecture.md b/docs/developer-guide/architecture.md index 150d0139ce..eb84ac8a9b 100644 --- a/docs/developer-guide/architecture.md +++ b/docs/developer-guide/architecture.md @@ -23,7 +23,7 @@ ESLint 有几个关键部分： * `lib/eslint.js` - this is the core `eslint` object that does code verifying based on configuration options. This file does no file I/O and does not interact with the `console` at all. For other Node.js programs that have JavaScript text to verify, they would be able to use this interface directly. -* `lib/eslint.js` - 这个是核心的`eslint`对象，负责根据配置选项进行代码验证。这个文件没有文件I/O操作，也不与`console`打交道。对于其他需要验证 Javascript 文本的 Node.js 程序而已，它们可以直接使用这个接口。 +* `lib/eslint.js` - 这个是核心的`eslint`对象，负责根据配置选项进行代码验证。这个文件没有文件 I/O 操作，也不与`console`打交道。对于其他需要验证 JavaScript 文本的 Node.js 程序而已，它们可以直接使用这个接口。 ## The `cli` object @@ -111,16 +111,16 @@ The main method of the `eslint` object is `verify()` and accepts two arguments: Once the AST is available, `estraverse` is used to traverse the AST from top to bottom. At each node, the `eslint` object emits an event that has the same name as the node type (i.e., "Identifier", "WithStatement", etc.). On the way back up the subtree, an event is emitted with the AST type name and suffixed with ":after", such as "Identifier:after" - this allows rules to take action both on the way down and on the way up in the traversal. Each event is emitted with the appropriate AST node available. -一旦AST是可用的，`estraverse`被用来从上到下遍历AST。在每个节点，`eslint`对象触发与该节点类型同名的一个事件（即 "Identifier"，"WithStatement" 等等）。在回退到子树上时，一个带有AST类型名称和":after"后缀的事件被触发，比如"Identifier:after" - 这允许规则在正向和逆向遍历开始起作用。每个事件在恰当的AST节点可用时触发。 +一旦AST是可用的，`estraverse`被用来从上到下遍历 AST。在每个节点，`eslint`对象触发与该节点类型同名的一个事件（即 "Identifier"， "WithStatement" 等等）。在回退到子树上时，一个带有 AST 类型名称和 ":after" 后缀的事件被触发，比如 "Identifier:after" - 这允许规则在正向和逆向遍历开始起作用。每个事件在恰当的 AST 节点可用时触发。 This object's responsibilities include: 这个对象的职责包括： * Inspecting JavaScript code strings -* 检查Javascript 代码字符串 +* 检查 JavaScript 代码字符串 * Creating an AST for the code -* 为代码创建AST +* 为代码创建 AST * Executing rules on the AST * 在AST上执行规则 * Reporting back the results of the execution @@ -135,7 +135,7 @@ This object may not: * Perform any asynchronous operations * 执行任何异步操作 * Use Node.js-specific features -* 使用 Node.js特定的功能 +* 使用 Node.js 特定的功能 * Access the file system * 访问文件系统 * Call `console.log()` or any other similar method diff --git a/docs/developer-guide/working-with-rules.md b/docs/developer-guide/working-with-rules.md index b36e39b32d..ee44efa867 100644 --- a/docs/developer-guide/working-with-rules.md +++ b/docs/developer-guide/working-with-rules.md @@ -46,7 +46,7 @@ module.exports.schema = [ Each rule is represented by a single object with several properties. The properties are equivalent to AST node types from [ESTree](https://github.com/estree/estree). For example, if your rule wants to know when an identifier is found in the AST, then add a method called "Identifier", such as: -每个规则都表现为一个非空对象。它的属性相当于 ESTree 中的 AST 节点类型。例如，如果你的规则想知道一个标识符什么时候在 AST 中被发现，添加一个叫做 "Identifier" 的方法，比如： +每个规则都表现为一个非空对象。它的属性相当于 [ESTree](https://github.com/estree/estree) 中的 AST 节点类型。例如，如果你的规则想知道一个标识符什么时候在 AST 中被发现，添加一个叫做 "Identifier" 的方法，比如： ```js module.exports = function(context) { diff --git a/docs/issue/autofixing.md b/docs/issue/autofixing.md index 637a707677..f031a3d9fa 100644 --- a/docs/issue/autofixing.md +++ b/docs/issue/autofixing.md @@ -9,7 +9,7 @@ layout: issue There have been a few issues recently with people asking to add more autofixing. This is definitely something we want to address, but we can't do it with the way autofixing works right now. This (unfortunately long) issue is meant to outline what we currently have, its limitations, and start towards thinking about how to fix autofix so we can use autofix in as many places as possible. -最近有一些要求增加更多自动修复的issue。自动修复我们肯定是要做的，但不是现在。在此，大概描述一下现阶段的情况，它的局限性，以及关于自动修复的一些思考，以便使我们在尽可能多的地方使用自动修复。 +最近有一些要求增加更多自动修复的 issue。自动修复我们肯定是要做的，但不是现在。在此，大概描述一下现阶段的情况，它的局限性，以及关于自动修复的一些思考，以便使我们在尽可能多的地方使用自动修复。 ### Intro @@ -17,7 +17,7 @@ There have been a few issues recently with people asking to add more autofixing. --- When ESLint first implemented autofixing, our belief was that it was primarily useful for making small changes, mostly whitespace and anything that could be contained within a single token. Most of the complaints people had about ESLint rules was that they hated going through and fixing alignment or adding/removing semicolons but loved the error catches. So naturally, I thought if we could get the whitespace and other small autofixes in, that would make people happy. It did, it's just that then we started getting requests to autofix more rules and we realized that the current system doesn't scale well. -ESLint最初实现自动修复时，我们的信念就是，它主要用于一些小的改变，主要是空白和单一的token。人们对于ESLint规则的大部分抱怨是他们讨厌经历和修复对齐或增删分号，但是喜欢错误的捕获。所以，我想过我们是否要把空白和其他小的自动修复添加进来，满足大家。我们已经做了，也就是那时起，我们开始收到对更多规则自动修复的请求，我们也意识到，现在的系统可扩展性并不是很好。 +ESLint 最初实现自动修复时，我们的信念就是，它主要用于一些小的改变，主要是空白和单一的 token。人们对于 ESLint 规则的大部分抱怨是他们讨厌经历和修复对齐或增删分号，但是喜欢错误的捕获。所以，我想过我们是否要把空白和其他小的自动修复添加进来，满足大家。我们已经做了，也就是那时起，我们开始收到对更多规则自动修复的请求，我们也意识到，现在的系统可扩展性并不是很好。 ### How it Works Today @@ -26,23 +26,23 @@ ESLint最初实现自动修复时，我们的信念就是，它主要用于一 Today's autofix is based on text and is latched onto how ESLint has always worked: -自动修复是基于文本的，而且强烈依赖于ESLint的工作机制: +自动修复是基于文本的，而且强烈依赖于 ESLint 的工作机制: 1. ESLint makes a single traversal through the AST of the file. -1. ESLint 通过文件的AST只做一次遍历。 +1. ESLint 通过文件的 AST 只做一次遍历。 2. Rules listen for different nodes and evaluate the AST as it goes, producing messages when it finds something wrong. -2. 遍历过程中，这些规则监听不同的节点和评估当前的AST，当发现错误时，就产出消息。 +2. 遍历过程中，这些规则监听不同的节点和评估当前的 AST，当发现错误时，就产出消息。 3. Rules can optionally specify a way to fix each message it reports. The fix is indicated by range offsets (the same as used in the range object on AST nodes). This fix is not guaranteed to be applied and will not even be attempted until after the complete traversal is finished. -3. 每条规则可以指定一种方式去进行修复。使用范围偏移表示要修复的位置（这和AST节点中rang对象的用法一样）。在遍历完成之前，并不能保证修复程序被调用，也不会尝试这么做。 +3. 每条规则可以指定一种方式去进行修复。使用范围偏移表示要修复的位置（这和 AST 节点中 range 对象的用法一样）。在遍历完成之前，并不能保证修复程序被调用，也不会尝试这么做。 4. After the traversal is complete, all of the proposed fixes are sorted in descending order of range location. So a fix at location 10 comes before a fix at 5. -4. 遍历完成之后，所有的修复根据rang的位置降序排列。所以处于位置10的修复比在位置5的修复要先行调用。 +4. 遍历完成之后，所有的修复根据 range 的位置降序排列。所以处于位置 10 的修复比在位置 5 的修复要先行调用。 5. The fixer attempts to apply the fixes in this order. If two fixes overlap in range, then only the first is applied. This continues until all potential fixes have been processed. @@ -50,7 +50,7 @@ Today's autofix is based on text and is latched onto how ESLint has always worke 6. If a fix is applied, then that message is removed from the lint results of the file. -6. 如果一个修复被应用，那么它产生的消息会从该文件的lint的结果中删除。 +6. 如果一个修复被应用，那么它产生的消息会从该文件的检测的结果中删除。 7. The remaining lint results are presented to the user. @@ -58,7 +58,7 @@ Today's autofix is based on text and is latched onto how ESLint has always worke Because of the single traversal, we can't apply the fixes as we go because it would affect other rules as it goes. For instance, if we changed a let to a const, that then pushes the ranges of everything in the tree by two, so when does that calculation happen? Also, each rule is triggered multiple times at different nodes, and many of the rules try to track things in between those triggers - the built-in assumption is that the tree looks the same as the first time the rule is triggered. -由于只会遍历一次，我们无法随意地进行修复，因为那些会影响到其他规则。比如，如果我们将let声明的变量改为了一个常量，然后将树中的所有范围记录两次，那么，什么时候进行计算呢？同时，每个规则在不同的节点上被多次触发，很多规则试图定位这些触发器之间的事情 -- 假定这颗树看起来和这条规则第一次被触发一样。 +由于只会遍历一次，我们无法随意地进行修复，因为那些会影响到其他规则。比如，如果我们将 let 声明的变量改为了一个常量，然后将树中的所有范围记录两次，那么，什么时候进行计算呢？同时，每个规则在不同的节点上被多次触发，很多规则试图定位这些触发器之间的事情 -- 假定这颗树看起来和这条规则第一次被触发一样。 ### Problems @@ -71,7 +71,7 @@ Due the single traversal mode, we have several problems: 1. It's possible that not all fixes will be applied. -1. 有可能所有的修复都不会被应用 +1. 有可能并非所有的修复都会被应用。 2. It's possible for a fix to be applied that violates a different rule. For instance, one rule could insert a comma while another requires a space after a comma. The rule requiring the space has no idea that a new comma was added because it's done after the rule has already executed. @@ -79,11 +79,11 @@ Due the single traversal mode, we have several problems: 3. It's possible for a fix to change scope evaluation. For instance, changing var to const has implications based on the functions or block statements using it. That can invalidate a whole host of rules because scope calculations are done once, before the traversal. -3. 修复的可能变化范围的评估。例如,改变var const影响基于函数或语句块的使用它。可以无效的一整套规则因为范围计算做了一次,在遍历。 +3. 修复可能改变范围的评估。例如，将函数或语句块内的 var 改为 const。可能导致整个规则无效，因为在遍历前，范围的计算已经结束。 4. It's possible for a fix to introduce an error into the program by changing the meaning of the code. -5. 一个修复，如果改变了代码的含义，很有可能导致程序出错。 +5. 一个修复如果改变了代码的含义，很有可能导致程序出错。 As a result of these problems, we decided to limit what we'd allow as fixes in core rules to whitespace and other small changes. Semicolons were a big pain point, so even though they aren't whitespace, we determined the value of fixing these was high enough to be worth any potential other problems. The same with string literals. We actually removed autofixing for === after we realized it would change the meaning of the condition and cause a runtime error. We then decided that any new autofixes would just be whitespace to avoid any other complications. @@ -100,7 +100,7 @@ Looking back, I think I made several design decisions that were incorrect. These 1. Autofix mode should just do fixes and not worry about unfixable rules. Right now it acts just like linting, outputting any messages it didn't fix. That seems unnecessary. -1. 自动修复模式应该只进行修复，无需关心不可修复的规则。但是现在，它既扮演者lint的角色，也会输出消息。这似乎是不必要的。 +1. 自动修复模式应该只进行修复，无需关心不可修复的规则。但是现在，它既扮演者 lint 的角色，也会输出消息。这似乎是不必要的。 2. The text-based fixes were a naive approach to autofixing that was targeted at whitespace fixes as a primary use case. It's clear text-based fixes aren't scaleable. @@ -108,7 +108,7 @@ Looking back, I think I made several design decisions that were incorrect. These 3. Trying to fit autofixing into the same single traversal system as the linting is too limiting. -3. 试图将自动修复融入到单一遍历系统的linting过程中，显得力不从心。 +3. 试图将自动修复融入到单一遍历系统的检测过程中，显得力不从心。 ### The Future @@ -126,11 +126,11 @@ So now that I've explained the current state of stuff, I think we have an opport 1. Autofix mode just does fixes and does not do any unfixable rule linting at all. (That means --fix doesn't output any linting problems.) -1. 自动修复模式只做修复，决不对不可修复的规则进行lint。（这意味着 --fix 不输入任何lint问题。） +1. 自动修复模式只做修复，决不对不可修复的规则进行检测。（这意味着 --fix 不输入任何lint问题。） 2. Autofix logic for each rule is contained with the rule file that does linting, not it another file. -2. 每条规则的自动修复逻辑包含在要lint的规则文件中，而不是其他文件。 +2. 每条规则的自动修复逻辑包含在要检测的规则文件中，而不是其他文件。 3. Autofix logic in rules is declarative and doesn't force rules to do something like if (mode === "fix") { fix() }. Basically, we can't throw away the way rules work today, there are too many core rules and plugins with rules to force everyone to rewrite in a dramatic way. @@ -142,11 +142,11 @@ So now that I've explained the current state of stuff, I think we have an opport 5. Regardless of fixes, ESLint must never output a file with illegal syntax as the final result. -5. 且不论修复，ESLint绝不输出一个有非法语法的文件作为最终结果。 +5. 且不论修复，ESLint 绝不输出一个有非法语法的文件作为最终结果。 6. Autofix should work for custom nodes that aren't part of the ESTree spec (I'm thinking about Flow, TypeScript, and other derivatives that add custom nodes into an ESTree AST). -6. 自动修复应该对非ESTree规范的自定义的节点起作用。（我正在考虑把Flow、TypeScript和其他添加自定义节点的衍生类库添加到AST）。 +6. 自动修复应该对非 ESTree 规范的自定义的节点起作用。（我正在考虑把 Flow、TypeScript 和其他添加自定义节点的衍生类库添加到 AST）。 ### Ideas: Config @@ -166,15 +166,15 @@ rules: This would be an extension of the work done in #3626 to allow "off", "warn", and "error" as options instead of 0, 1, and 2. -这将是对[#3626](https://github.com/eslint/eslint/issues/3626)的一个扩展，它允许使用"off"、"warn"和 "error" 而不是 0，1和2。 +这将是对[#3626](https://github.com/eslint/eslint/issues/3626)的一个扩展，它允许使用 "off"、"warn" 和 "error" 而不是 0，1 和 2。 I think this would be a big win because it gives us a good idea about how to save time: during fixing, we just load the rules marked as "fix" and ignore the rest. That should cut down on the runtime (so long as not every rule is fixable!) -我想这将是一个重大的胜利，因为对于如何节省时间，它给我们提供了一个很好的想法： 在修复期间，我们只加载带有“fix”标记的规则，忽略其他的规则。在运行时，这些时间是应该减掉的（只要不是每条规则都是可修复的！） +我想这将是一个重大的胜利，因为对于如何节省时间，它给我们提供了一个很好的想法： 在修复期间，我们只加载带有 "fix" 标记的规则，忽略其他的规则。在运行时，这些时间是应该减掉的（只要不是每条规则都是可修复的！） Open Question: When not running in fix mode, what does "fix" mean? Is it "warn" or "error"? -**疑问：** 什么时候不运行在修复模式下？“fix” 是什么意思？ “warn” 还是 “error” ? +**疑问：**什么时候不运行在修复模式下？ "fix" 是什么意思？ "warn" 还是 "error" ? ### Concerns @@ -191,7 +191,7 @@ Some other concerns I have with changes are: 2. Do we need to do nonwhitespace rules first and whitespace rules second? Or do we just bite the bullet and say we always need at least two passes per file to get as many fixes as possible? (Or just keep doing passes until all fixes are applied?) -2. 我们是否需要先处理非空白规则，然后再处理空白的规则？或者我们只是咬紧牙关说每个文件我们总是需要至少传递两个，以获取尽可能多的修复？（或者一直传递直到所有的修复都被应用？） +2. 我们是否需要先处理非空白规则，然后再处理空白的规则？或者我们只是咬紧牙关说每个文件我们总是需要至少传递两个，以获取尽可能多的修复？(或者一直传递直到所有的修复都被应用？) 3. How will this work with code path analysis? Changing nodes around affects code paths dramatically. @@ -199,7 +199,7 @@ Some other concerns I have with changes are: 4. How will this work with escope and scope evaluation? Will we have to run scope analysis multiple times? How will that affect performance -4. 这将如何处理escope和 scope的评估？我们是否需要多次运行scope分析？这将如何影响性能？ +4. 这将如何处理 escope 和 scope 的评估？我们是否需要多次运行 scope 分析？这将如何影响性能？ ### Next Steps diff --git a/docs/rules/block-scoped-var.md b/docs/rules/block-scoped-var.md index 26867591dc..56c364ac48 100644 --- a/docs/rules/block-scoped-var.md +++ b/docs/rules/block-scoped-var.md @@ -12,14 +12,13 @@ proofreader: qifeigit The `block-scoped-var` rule generates warnings when variables are used outside of the block in which they were defined. This emulates C-style block scope. -当变量在其被定义的范围之外被使用时，会违反block-scoped-var规则，从而被警告。 -这种解析方式模拟了c语言中的块级作用域。 +当变量在其被定义的范围之外被使用时，该规则会发出警告。这种解析方式模拟了 C 语言中的块级作用域。 ## Rule Details This rule aims to reduce the usage of variables outside of their binding context and emulate traditional block scope from other languages. This is to help newcomers to the language avoid difficult bugs with variable hoisting. -此规则借鉴其他语言的块级作用域概念，旨在用来减少变量跨作用域使用情况的发生。此规则可帮助语言初学者避免因变量声明提升而产生的bugs。 +此规则借鉴其他语言的块级作用域概念，旨在用来减少变量跨作用域使用情况的发生。此规则可帮助语言初学者避免因变量声明提升而产生的 bug。 Examples of **incorrect** code for this rule: diff --git a/docs/rules/comma-dangle.md b/docs/rules/comma-dangle.md index 1543f4614f..ab783c2304 100644 --- a/docs/rules/comma-dangle.md +++ b/docs/rules/comma-dangle.md @@ -12,7 +12,7 @@ proofreader: molee1905 Trailing commas in object literals are valid according to the ECMAScript 5 (and ECMAScript 3!) spec. However, IE8 (when not in IE8 document mode) and below will throw an error when it encounters trailing commas in JavaScript. -根据 ECMAScript5(和 ECMAScript3!)规范，对象字面量中的拖尾逗号是合法的。然而，在IE8（非IE8文档模式）下，当在 JavaScript 出现拖尾逗号，以下情况下将抛出错误。 +根据 ECMAScript5 (和 ECMAScript3!)规范，对象字面量中的拖尾逗号是合法的。然而，在 IE8（非 IE8 文档模式）下，当在 JavaScript 出现拖尾逗号，以下情况下将抛出错误。 ```js var foo = { diff --git a/docs/rules/index.md b/docs/rules/index.md index 0a30b3541f..92cd1329dd 100644 --- a/docs/rules/index.md +++ b/docs/rules/index.md @@ -518,7 +518,7 @@ These rules existed in a previous version of ESLint but have since been replaced * [no-empty-class](no-empty-class): disallow the use of empty character classes in regular expressions (replaced by [no-empty-character-class](no-empty-character-class)) * [no-empty-class](no-empty-class): 禁止在正则表达式中使用空字符 (替换为 [no-empty-character-class](no-empty-character-class)) * [no-empty-label](no-empty-label): disallow use of labels for anything other than loops and switches (replaced by [no-labels](no-labels)) -* [no-empty-label](no-empty-label): 禁用标签，除了循环和switch外(替换为 [no-labels](no-labels)) +* [no-empty-label](no-empty-label): 禁用标签，除了循环和 switch 外(替换为 [no-labels](no-labels)) * [no-extra-strict](no-extra-strict): disallow unnecessary use of `"use strict";` when already in strict mode (replaced by [strict](strict)) * [no-extra-strict](no-extra-strict): 当已经处于严格模式下，禁用不必要的`"use strict";` (替换为 [strict](strict)) * [no-reserved-keys](no-reserved-keys): disallow reserved words being used as object literal keys (replaced by [quote-props](quote-props)) @@ -526,7 +526,7 @@ These rules existed in a previous version of ESLint but have since been replaced * [no-space-before-semi](no-space-before-semi): disallow space before semicolon (replaced by [semi-spacing](semi-spacing)) * [no-space-before-semi](no-space-before-semi): 禁用分号前空格 (替换为 [semi-spacing](semi-spacing)) * [no-wrap-func](no-wrap-func): disallow wrapping of non-IIFE statements in parens (replaced by [no-extra-parens](no-extra-parens)) -* [no-wrap-func](no-wrap-func): 禁止非IIFE语句括在括号中 (替换为 [no-extra-parens](no-extra-parens)) +* [no-wrap-func](no-wrap-func): 禁止非 IIFE 语句括在括号中 (替换为 [no-extra-parens](no-extra-parens)) * [space-after-function-name](space-after-function-name): require a space after function names (replaced by [space-before-function-paren](space-before-function-paren)) * [space-after-function-name](space-after-function-name): 要求函数名后有一个空格 (替换为 [space-before-function-paren](space-before-function-paren)) * [space-after-keywords](space-after-keywords): require a space after certain keywords (fixable) (replaced by [keyword-spacing](keyword-spacing)) diff --git a/docs/rules/no-control-regex.md b/docs/rules/no-control-regex.md index 3ce713d139..bd55b9ccb1 100644 --- a/docs/rules/no-control-regex.md +++ b/docs/rules/no-control-regex.md @@ -12,7 +12,7 @@ proofreader: molee1905 Control characters are special, invisible characters in the ASCII range 0-31. These characters are rarely used in JavaScript strings so a regular expression containing these characters is most likely a mistake. -在ASCII中，0-31范围内的控制字符是特殊的不可视字符。这些字符很少被用在 JavaScript 字符串中，所以包含这些字符的正则表达式很有可能是错误的。 +在 ASCII 中，0-31 范围内的控制字符是特殊的不可视字符。这些字符很少被用在 JavaScript 字符串中，所以包含这些字符的正则表达式很有可能是错误的。 ## Rule Details diff --git a/docs/rules/no-duplicate-case.md b/docs/rules/no-duplicate-case.md index 415117bb69..5bd9f36a45 100644 --- a/docs/rules/no-duplicate-case.md +++ b/docs/rules/no-duplicate-case.md @@ -12,13 +12,13 @@ proofreader: molee1905 If a switch statement has duplicate case labels, it is likely that a programmer copied a case but forgot to change the label. -如果在 switch 语句中出现重复 case 标签，很有可能是开发者拷贝了一个case语句，并且忘了改标签。 +如果在 switch 语句中出现重复 case 标签，很有可能是开发者拷贝了一个 case 语句，并且忘了改标签。 ## Rule Details This rule is aimed at eliminating duplicate case labels in switch statements -该检查报告 JavaScript switch 语句中出现重复 case 标签的情况。 +该规则旨在消除重复 switch 语句中的重复 case 标签。 Examples of **incorrect** code for this rule: diff --git a/docs/rules/no-undef.md b/docs/rules/no-undef.md index e681ab8124..e9435d8fbf 100644 --- a/docs/rules/no-undef.md +++ b/docs/rules/no-undef.md @@ -8,7 +8,7 @@ proofreader: coocon # Disallow Undeclared Variables (no-undef) -# 不允许使用未申明变量 (no-undef) +# 禁用未声明的变量 (no-undef) This rule can help you locate potential ReferenceErrors resulting from misspellings of variable and parameter names, or accidental implicit globals (for example, from forgetting the `var` keyword in a `for` loop initializer). @@ -45,6 +45,8 @@ b = 10; The `b:true` syntax in `/*global */` indicates that assignment to `b` is correct. +`/*global */`中的`b:true`表示可以对`b`进行赋值。 + Examples of **incorrect** code for this rule with `global` declaration: 有`global`声明时，该规则的 **错误**代码示例： diff --git a/docs/user-guide/command-line-interface.md b/docs/user-guide/command-line-interface.md index 6a96a6cac0..124a224558 100644 --- a/docs/user-guide/command-line-interface.md +++ b/docs/user-guide/command-line-interface.md @@ -135,7 +135,7 @@ This example uses the configuration file at `~/my-eslint.json`. It also accepts a module ID of [sharable config](../developer-guide/shareable-configs). -它还接受[sharable config](../developer-guide/shareable-configs)的一个模块的ID。 +它还接受[sharable config](../developer-guide/shareable-configs)的一个模块的 ID。 Example: @@ -317,7 +317,7 @@ This option specifies rules to be used. These rules will be merged with any rule If the rule is defined within a plugin you have to prefix the rule ID with the plugin name and a `/`. -如果这个规则定义在插件内，你必须在规则ID前使用插件名和`/`，即`插件名/规则ID`。 +如果这个规则定义在插件内，你必须在规则 ID 前使用插件名和`/`，即`插件名/规则ID`。 Examples: @@ -507,7 +507,7 @@ This option instructs ESLint to try to fix as many issues as possible. The fixes 1. This option throws an error when code is piped to ESLint. -1. 当代码传递给 ESLint时，这个选项抛出一个错误。 +1. 当代码传递给 ESLint 时，这个选项抛出一个错误。 1. This option has no effect on code that uses processors. diff --git a/docs/user-guide/configuring.md b/docs/user-guide/configuring.md index 87c92b5b9a..35360780ee 100644 --- a/docs/user-guide/configuring.md +++ b/docs/user-guide/configuring.md @@ -104,7 +104,7 @@ Here's an example `.eslintrc.json` file: Setting parser options helps ESLint determine what is a parsing error. All language options are `false` by default. -设置解析器选项帮助ESLint确定什么是解析错误，所有语言选项默认都是`false`。 +设置解析器选项帮助 ESLint 确定什么是解析错误，所有语言选项默认都是`false`。 ## Specifying Parser @@ -128,7 +128,7 @@ ESLint 默认使用[Espree](https://github.com/eslint/espree)作为其解析器 Note that even with these compatibilities, there are no guarantees that an external parser will work correctly with ESLint and ESLint will not fix bugs related to incompatibilities with other parsers. -注意，即使满足这些兼容性，也不能保证一个外部解析器可以与ESLint正常工作，ESLint也不会修复与其它解析器不兼容的相关 bug。 +注意，即使满足这些兼容性，也不能保证一个外部解析器可以与 ESLint 正常工作，ESLint 也不会修复与其它解析器不兼容的相关 bug。 To indicate the npm module to use as your parser, specify it using the `parser` option in your `.eslintrc` file. For example, the following specifies to use Esprima instead of Espree: @@ -198,7 +198,7 @@ An environment defines global variables that are predefined. The available envir * `jasmine` - adds all of the Jasmine testing global variables for version 1.3 and 2.0. -* `jasmine` - 添加所有的 Jasmine版本 1.3 和 2.0 的测试全局变量。 +* `jasmine` - 添加所有的 Jasmine 版本 1.3 和 2.0 的测试全局变量。 * `jest` - Jest global variables. @@ -373,11 +373,11 @@ And in YAML: The [no-undef](../rules/no-undef) rule will warn on variables that are accessed but not defined within the same file. If you are using global variables inside of a file then it's worthwhile to define those globals so that ESLint will not warn about their usage. You can define global variables either using comments inside of a file or in the configuration file. -当变量被访问，但没有定义在同一文件里时，[no-undef](../rules/no-undef) 规则会发出警告。如果你想在一个文件里使用全局变量，推荐你定义这些全局变量，这样ESLint就不会发出警告了。你可以使用注释或在配置文件中定义全局变量。 +当访问未定义的变量时，[no-undef](../rules/no-undef) 规则将发出警告。如果你想在一个文件里使用全局变量，推荐你定义这些全局变量，这样 ESLint 就不会发出警告了。你可以使用注释或在配置文件中定义全局变量。 To specify globals using a comment inside of your JavaScript file, use the following format: -在你的 JavaScript 文件中用注释指定全局变量，使用如下格式： +在你的 JavaScript 文件中，用注释指定全局变量，格式如下： ```js /*global var1, var2*/ @@ -385,7 +385,7 @@ To specify globals using a comment inside of your JavaScript file, use the follo This defines two global variables, `var1` and `var2`. If you want to optionally specify that these global variables should never be written to (only read), then you can set each with a `false` flag: -这里定义了两个全局变量：`var1` 和 `var2`。如果你想指定这些变量为只读的，你可以将它们设置为`false`： +这里定义了两个全局变量：`var1` 和 `var2`。如果你想指定这些变量不应被重写（只读），你可以将它们设置为`false`： ```js /*global var1:false, var2:false*/ @@ -393,7 +393,7 @@ This defines two global variables, `var1` and `var2`. If you want to optionally To configure global variables inside of a configuration file, use the `globals` key and indicate the global variables you want to use. Set each global variable name equal to `true` to allow the variable to be overwritten or `false` to disallow overwriting. For example: -在配置文件里配置全局变量时，使用关键字`globals`键表示你要使用的全局变量。设置每个变量等于`true`允许变量被重写，或`false`不允许被重写。比如： +在配置文件里配置全局变量时，使用键`globals`指出你要使用的全局变量。设置每个变量等于`true`允许变量被重写，或`false`不允许被重写。比如： ```json { @@ -580,7 +580,7 @@ In these configuration files, the rule `plugin1/rule1` comes from the plugin nam **Note:** When specifying rules from plugins, make sure to omit `eslint-plugin-`. ESLint uses only the unprefixed name internally to locate rules. -**注意：** 当指定从插件来的规则时，确保删除`eslint-plugin-`前缀。ESLint 在内部只使用没有前缀的名称去定位规则。 +**注意：**当指定从插件来的规则时，确保删除`eslint-plugin-`前缀。ESLint 在内部只使用没有前缀的名称去定位规则。 To temporarily disable rule warnings in your file use the following format: @@ -643,7 +643,7 @@ alert('foo'); **Note:** Comments that disable warnings for a portion of a file tell ESLint not to report rule violations for the disabled code. ESLint parses the entire file, so disabled code still needs to be syntactically valid JavaScript. -**注意：** 为文件的某部分禁用警告的注释，告诉 ESLint 不要对禁用的代码报告规则的冲突。ESLint 解析整个文件，所以禁用的代码仍需要是有效的 JavaScript语法。 +**注意：**为文件的某部分禁用警告的注释，告诉 ESLint 不要对禁用的代码报告规则的冲突。ESLint 解析整个文件，所以禁用的代码仍需要是有效的 JavaScript语法。 ## Adding Shared Settings @@ -651,7 +651,7 @@ alert('foo'); ESLint supports adding shared settings into configuration file. You can add `settings` object to ESLint configuration file and it will be supplied to every rule that will be executed. This may be useful if you are adding custom rules and want them to have access to the same information and be easily configurable. -ESLint支持在配置文件添加共享设置。你可以添加`settings`对象到配置文件，它将提供给每一个将被执行的规则。如果你想添加的自定义规则而且使它们可以访问到相同的信息，这将会很有用，并且很容易配置。 +ESLint 支持在配置文件添加共享设置。你可以添加`settings`对象到配置文件，它将提供给每一个将被执行的规则。如果你想添加的自定义规则而且使它们可以访问到相同的信息，这将会很有用，并且很容易配置。 In JSON: @@ -687,7 +687,7 @@ There are two ways to use configuration files. The first is to save the file whe The second way to use configuration files is via `.eslintrc.*` and `package.json` files. ESLint will automatically look for them in the directory of the file to be linted, and in successive parent directories all the way up to the root directory of the filesystem. This option is useful when you want different configurations for different parts of a project or when you want others to be able to use ESLint directly without needing to remember to pass in the configuration file. -第二种方式是通过`.eslintrc.*`和`package.json`。ESLint将自动在要检测的文件目录里寻找它们，紧接着是父级目录，一直到文件系统的根目录。当你想对一个项目的不同部分的使用不同配置，或当你希望别人能够直接使用ESLint，而无需记住要在配置文件中传递什么，这种方式就很有用。 +第二种方式是通过`.eslintrc.*`和`package.json`。ESLint 将自动在要检测的文件目录里寻找它们，紧接着是父级目录，一直到文件系统的根目录。当你想对一个项目的不同部分的使用不同配置，或当你希望别人能够直接使用 ESLint，而无需记住要在配置文件中传递什么，这种方式就很有用。 In each case, the settings in the configuration file override default settings. @@ -781,7 +781,7 @@ If there is an `.eslintrc` and a `package.json` file found in the same directory **Note:** If you have a personal configuration file in your home directory (`~/.eslintrc`), it will only be used if no other configuration files are found. Since a personal configuration would apply to everything inside of a user's directory, including third-party code, this could cause problems when running ESLint. -**注意：** 如果在你的主目录下有一个自定义的配置文件(`~/.eslintrc`)，如果没有其它配置文件时它才会被使用。因为个人配置将适用于用户目录下的所有目录和文件，包括第三方的代码，当ESLint运行时肯能会导致问题。 +**注意：**如果在你的主目录下有一个自定义的配置文件(`~/.eslintrc`)，如果没有其它配置文件时它才会被使用。因为个人配置将适用于用户目录下的所有目录和文件，包括第三方的代码，当 ESLint 运行时肯能会导致问题。 By default, ESLint will look for configuration files in all parent folders up to the root directory. This can be useful if you want all of your projects to follow a certain convention, but can sometimes lead to unexpected results. To limit ESLint to a specific project, place `"root": true` inside the `eslintConfig` field of the `package.json` file or in the `.eslintrc.*` file at your project's root level. ESLint will stop looking in parent folders once it finds a configuration with `"root": true`. @@ -967,11 +967,11 @@ In this example, the `eslint-plugin-myplugin` package contains configuration nam **Important:** When you are extending from the configuration bundled with plugins, you need to start with `plugin:` prefix as well as specify configuration name after the slash. You may optionally omit the `eslint-plugin-` prefix. -**重要：** 当你从配置的插件中进行扩展是，你需要以`plugin:`前缀开头，在斜线后指定配置名称。你可以选择忽略`eslint-plugin-`前缀。 +**重要：**当你从配置的插件中进行扩展是，你需要以`plugin:`前缀开头，在斜线后指定配置名称。你可以选择忽略`eslint-plugin-`前缀。 **Note:** For configuration files in your home directory, or in any path that isn't an ancestor to the location of ESLint (either globally or locally), `extends` is resolved from the path of the project using ESLint (typically the current working directory) rather than relative to the file itself. -**注意：** 对于在你的主目录或其他任何非 ESLint 父级路径中的配置文件，`extends`是使用的是项目的路径（通常是当前工作目录）而不是相对于要检测的文件本身。 +**注意：**对于在你的主目录或其他任何非 ESLint 父级路径中的配置文件，`extends`是使用的是项目的路径（通常是当前工作目录）而不是相对于要检测的文件本身。 ## Comments in Configuration Files @@ -1008,7 +1008,7 @@ Currently the sole method for telling ESLint which file extensions to lint is by You can tell ESLint to ignore specific files and directories by creating an `.eslintignore` file in your project's root directory. The `.eslintignore` file is a plain text file where each line is a glob pattern indicating which paths should be omitted from linting. For example, the following will omit all JavaScript files: -你可以通过在项目根目录创建一个`.eslintignore`文件告诉 ESLint 去忽略特定的文件和目录。`.eslintignore`文件是一个纯文本文件，其中的每一行都是一个glob模式表明哪些路径应该忽略检测。例如，以下将忽略所有的 JavaScript 文件： +你可以通过在项目根目录创建一个`.eslintignore`文件告诉 ESLint 去忽略特定的文件和目录。`.eslintignore`文件是一个纯文本文件，其中的每一行都是一个 glob 模式表明哪些路径应该忽略检测。例如，以下将忽略所有的 JavaScript 文件： ```text **/*.js