Docs: Fix typos (#9751)

* Docs: Fix typos

* s/RegExp/Regular Expression/

README.md

@@ -188,7 +188,7 @@ According to our policy, any minor update may report more errors than the previo
 
 ### How is ESLint different from JSHint?
 
-The most significant difference is that ESlint has pluggable linting rules. That means you can use the rules it comes with, or you can extend it with rules created by others or by yourself!
+The most significant difference is that ESLint has pluggable linting rules. That means you can use the rules it comes with, or you can extend it with rules created by others or by yourself!
 
 ### How does ESLint performance compare to JSHint?
 

docs/developer-guide/working-with-rules.md

@@ -375,7 +375,7 @@ In the preceding example, the error level is assumed to be the first argument. I
 
 To learn more about JSON Schema, we recommend looking at some [examples](http://json-schema.org/examples.html) to start, and also reading [Understanding JSON Schema](http://spacetelescope.github.io/understanding-json-schema/) (a free ebook).
 
-**Note:** Currently you need to use full JSON Schema object rather than array in case your schema has references ($ref), because in case of array format eslint transforms this array into a single schema without updating references that makes them incorrect (they are ignored).
+**Note:** Currently you need to use full JSON Schema object rather than array in case your schema has references ($ref), because in case of array format ESLint transforms this array into a single schema without updating references that makes them incorrect (they are ignored).
 
 ### Getting the Source
 

docs/rules/camelcase.md

@@ -1,6 +1,6 @@
-# Require Camelcase (camelcase)
+# Require CamelCase (camelcase)
 
-When it comes to naming variables, style guides generally fall into one of two camps: camelcase (`variableName`) and underscores (`variable_name`). This rule focuses on using the camelcase approach. If your style guide calls for camelcasing your variable names, then this rule is for you!
+When it comes to naming variables, style guides generally fall into one of two camps: camelcase (`variableName`) and underscores (`variable_name`). This rule focuses on using the camelcase approach. If your style guide calls for camelCasing your variable names, then this rule is for you!
 
 ## Rule Details
 

docs/rules/eol-last.md

@@ -10,7 +10,7 @@ This rule enforces at least one newline (or absence thereof) at the end
 of non-empty files.
 
 Prior to v0.16.0 this rule also enforced that there was only a single line at
-the end of the file. If you still want this behaviour, consider enabling
+the end of the file. If you still want this behavior, consider enabling
 [no-multiple-empty-lines](no-multiple-empty-lines.md) with `maxEOF` and/or
 [no-trailing-spaces](no-trailing-spaces.md).
 

docs/rules/lines-between-class-members.md

@@ -44,8 +44,8 @@ String option:
 
 Object option:
 
-* `"exceptAfterSingleLine": false`(default) **do not** skip checking empty lines after singleline class members
-* `"exceptAfterSingleLine": true` skip checking empty lines after singleline class members
+* `"exceptAfterSingleLine": false`(default) **do not** skip checking empty lines after single-line class members
+* `"exceptAfterSingleLine": true` skip checking empty lines after single-line class members
 
 Examples of **incorrect** code for this rule with the string option:
 

docs/rules/no-array-constructor.md

@@ -1,7 +1,7 @@
 # disallow `Array` constructors (no-array-constructor)
 
 Use of the `Array` constructor to construct a new array is generally
-discouraged in favour of array literal notation because of the single-argument
+discouraged in favor of array literal notation because of the single-argument
 pitfall and because the `Array` global may be redefined. The exception is when
 the Array constructor is used to intentionally create sparse arrays of a
 specified size by giving the constructor a single numeric argument.

docs/rules/no-div-regex.md

@@ -1,4 +1,4 @@
-# Disallow Regexs That Look Like Division (no-div-regex)
+# Disallow Regular Expressions That Look Like Division (no-div-regex)
 
 Require regex literals to escape division operators.
 

docs/rules/no-irregular-whitespace.md

@@ -8,7 +8,7 @@ Known issues these spaces cause:
 
 * Zero Width Space
     * Is NOT considered a separator for tokens and is often parsed as an `Unexpected token ILLEGAL`
-    * Is NOT shown in modern browsers making code repository software expected to resolve the visualisation
+    * Is NOT shown in modern browsers making code repository software expected to resolve the visualization
 * Line Separator
     * Is NOT a valid character within JSON which would cause parse errors
 

docs/rules/no-lone-blocks.md

@@ -44,7 +44,7 @@ function bar() {
 }
 ```
 
-Examples of **correct** code for this rule with es6 environment:
+Examples of **correct** code for this rule with ES6 environment:
 
 ```js
 /*eslint no-lone-blocks: "error"*/
@@ -80,7 +80,7 @@ aLabel: {
 }
 ```
 
-Examples of **correct** code for this rule with es6 environment and strict mode via `"parserOptions": { "sourceType": "module" }` in the ESLint configuration or `"use strict"` directive in the code:
+Examples of **correct** code for this rule with ES6 environment and strict mode via `"parserOptions": { "sourceType": "module" }` in the ESLint configuration or `"use strict"` directive in the code:
 
 ```js
 /*eslint no-lone-blocks: "error"*/

docs/rules/object-shorthand.md

@@ -90,8 +90,8 @@ The rule takes an option which specifies when it should be applied. It can be se
 * `"methods"` ensures the method shorthand is used (also applies to generators).
 * `"properties"` ensures the property shorthand is used (where the key and variable name match).
 * `"never"` ensures that no property or method shorthand is used in any object literal.
-* `"consistent"` ensures that either all shorthand or all longform will be used in an object literal.
-* `"consistent-as-needed"` ensures that either all shorthand or all longform will be used in an object literal, but ensures all shorthand whenever possible.
+* `"consistent"` ensures that either all shorthand or all long-form will be used in an object literal.
+* `"consistent-as-needed"` ensures that either all shorthand or all long-form will be used in an object literal, but ensures all shorthand whenever possible.
 
 You can set the option in configuration like this:
 
@@ -103,7 +103,7 @@ You can set the option in configuration like this:
 
 Additionally, the rule takes an optional object configuration:
 
-* `"avoidQuotes": true` indicates that longform syntax is preferred whenever the object key is a string literal (default: `false`). Note that this option can only be enabled when the string option is set to `"always"`, `"methods"`, or `"properties"`.
+* `"avoidQuotes": true` indicates that long-form syntax is preferred whenever the object key is a string literal (default: `false`). Note that this option can only be enabled when the string option is set to `"always"`, `"methods"`, or `"properties"`.
 * `"ignoreConstructors": true` can be used to prevent the rule from reporting errors for constructor functions. (By default, the rule treats constructors the same way as other functions.) Note that this option can only be enabled when the string option is set to `"always"` or `"methods"`.
 * `"avoidExplicitReturnArrows": true` indicates that methods are preferred over explicit-return arrow functions for function properties. (By default, the rule allows either of these.) Note that this option can only be enabled when the string option is set to `"always"` or `"methods"`.
 

docs/rules/sort-imports.md

@@ -165,7 +165,7 @@ There are four different styles and the default member syntax sort order is:
 * `multiple` - import multiple members.
 * `single` - import single member.
 
-All four options must be specified in the array, but you can customise their order.
+All four options must be specified in the array, but you can customize their order.
 
 Examples of **incorrect** code for this rule with the default `{ "memberSyntaxSortOrder": ["none", "all", "multiple", "single"] }` option:
 

docs/rules/space-before-keywords.md

@@ -28,7 +28,7 @@ must be preceded by at least one space. If `"never"` then no spaces will be allo
 the keywords `else`, `while` (do...while), `finally` and `catch`. The default value is `"always"`.
 
 This rule will allow keywords to be preceded by an opening curly brace (`{`). If you wish to alter
-this behaviour, consider using the [block-spacing](block-spacing.md) rule.
+this behavior, consider using the [block-spacing](block-spacing.md) rule.
 
 Examples of **incorrect** code for this rule with the default `"always"` option:
 

docs/rules/vars-on-top.md

@@ -2,7 +2,7 @@
 
 The `vars-on-top` rule generates warnings when variable declarations are not used serially at the top of a function scope or the top of a program.
 By default variable declarations are always moved (“hoisted”) invisibly to the top of their containing scope by the JavaScript interpreter.
-This rule forces the programmer to represent that behaviour by manually moving the variable declaration to the top of its containing scope.
+This rule forces the programmer to represent that behavior by manually moving the variable declaration to the top of its containing scope.
 
 ## Rule Details
 

docs/user-guide/configuring.md

@@ -259,7 +259,7 @@ And in YAML:
     - eslint-plugin-plugin2
 ```
 
-**Note:** Due to the behaviour of Node's `require` function, a globally-installed instance of ESLint can only use globally-installed ESLint plugins, and locally-installed version can only use *locally-installed* plugins. Mixing local and global plugins is not supported.
+**Note:** Due to the behavior of Node's `require` function, a globally-installed instance of ESLint can only use globally-installed ESLint plugins, and locally-installed version can only use *locally-installed* plugins. Mixing local and global plugins is not supported.
 
 ## Configuring Rules