Docs: Achieve consistent order of h2 in rule pages

Author: pedrottimark

docs/rules/callback-return.md

@@ -57,7 +57,7 @@ The rule takes a single option, which is an array of possible callback names.
 callback-return: [2, ["callback", "cb", "next"]]
 ```
 
-## Gotchas
+## Known Limitations
 
 There are several cases of bad behavior that this rule will not catch and even a few cases where
 the rule will warn even though you are handling your callbacks correctly. Most of these issues arise

docs/rules/func-style.md

@@ -62,6 +62,32 @@ An additional option object can be added with a property `"allowArrowFunctions"`
 "func-style": [2, "expression", { "allowArrowFunctions": true }]
 ```
 
+The following patterns are considered problems:
+
+```js
+/*eslint func-style: [2, "expression"]*/
+
+function foo() {
+    // ...
+}
+```
+
+The following patterns are not considered problems:
+
+```js
+/*eslint func-style: [2, "expression"]*/
+
+var foo = function() {
+    // ...
+};
+```
+
+```js
+/*eslint func-style: [2, "declaration", { "allowArrowFunctions": true }]*/
+
+var foo = () => {};
+```
+
 ### "declaration"
 
 This reports an error if any function expressions are used where function declarations are expected. You can specify to use expressions instead:
@@ -70,8 +96,6 @@ This reports an error if any function expressions are used where function declar
 "func-style": [2, "declaration"]
 ```
 
-## Examples
-
 The following patterns are considered problems:
 
 ```js
@@ -82,14 +106,6 @@ var foo = function() {
 };
 ```
 
-```js
-/*eslint func-style: [2, "expression"]*/
-
-function foo() {
-    // ...
-}
-```
-
 ```js
 /*eslint func-style: [2, "declaration"]*/
 
@@ -111,20 +127,6 @@ SomeObject.foo = function() {
 };
 ```
 
-```js
-/*eslint func-style: [2, "expression"]*/
-
-var foo = function() {
-    // ...
-};
-```
-
-```js
-/*eslint func-style: [2, "declaration", { "allowArrowFunctions": true }]*/
-
-var foo = () => {};
-```
-
 
 ## When Not To Use It
 

docs/rules/no-ex-assign.md

@@ -41,11 +41,7 @@ try {
 }
 ```
 
-## Notes
-
-Related aside: there are some interesting caveats in IE 6-8 where the exception identifier will leak into the outer scope causing some unexpected behavior. Ben Alman has a [great article](http://weblog.bocoup.com/the-catch-with-try-catch/) that explains this behavior in detail
-
 ## Further Reading
 
 * [Do not assign to the exception parameter](http://jslinterrors.com/do-not-assign-to-the-exception-parameter/)
-* [The "catch" with try...catch -- Ben Alman](http://weblog.bocoup.com/the-catch-with-try-catch/)
+* [The "catch" with try...catch](http://weblog.bocoup.com/the-catch-with-try-catch/) by Ben Alman explains how the exception identifier can leak into the outer scope in IE 6-8

docs/rules/no-extra-label.md

@@ -71,12 +71,12 @@ C: switch (a) {
 }
 ```
 
+## When Not To Use It
+
+If you don't want to be notified about usage of labels, then it's safe to disable this rule.
+
 ## Related Rules
 
 * [no-labels](./no-labels.md)
 * [no-label-var](./no-label-var.md)
 * [no-unused-labels](./no-unused-labels.md)
-
-## When Not To Use It
-
-If you don't want to be notified about usage of labels, then it's safe to disable this rule.

docs/rules/no-floating-decimal.md

@@ -33,14 +33,14 @@ var num = 0.5;
 var num = 2.0;
 ```
 
-## Compatibility
-
-* **JSHint**: W008
-
 ## When Not To Use It
 
 If you aren't concerned about misinterpreting floating decimal point values, then you can safely turn this rule off.
 
+## Compatibility
+
+* **JSHint**: W008
+
 ## Further Reading
 
 * [A leading decimal point can be confused with a dot](http://jslinterrors.com/a-leading-decimal-point-can-be-confused-with-a-dot-a/)

docs/rules/no-invalid-regexp.md

@@ -28,7 +28,7 @@ new RegExp
 this.RegExp('[')
 ```
 
-## New ECMAScript 6 Flags
+## Environments
 
 ECMAScript 6 adds the "u" ([unicode](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-get-regexp.prototype.unicode)) and "y" ([sticky](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-get-regexp.prototype.sticky)) flags. You can enable these to be recognized as valid by setting the ECMAScript version to 6 in your [ESLint configuration](../user-guide/configuring).
 

docs/rules/no-invalid-this.md

@@ -27,7 +27,7 @@ And this rule allows `this` keywords in functions below:
 
 Otherwise are considered problems.
 
-### The following patterns are considered problems:
+The following patterns are considered problems:
 
 This rule warns below **only** under the strict mode.
 Please note your code in ES2015 Modules/Classes is always the strict mode.
@@ -80,7 +80,7 @@ foo.forEach(function() {
 });
 ```
 
-### The following patterns are not considered problems:
+The following patterns are not considered problems:
 
 ```js
 /*eslint no-invalid-this: 2*/

docs/rules/no-label-var.md

@@ -41,12 +41,12 @@ q:
 
 If you don't want to be notified about usage of labels, then it's safe to disable this rule.
 
+## Further Reading
+
+* ['{a}' is a statement label](http://jslinterrors.com/a-is-a-statement-label/)
+
 ## Related Rules
 
 * [no-extra-label](./no-extra-label.md)
 * [no-labels](./no-labels.md)
 * [no-unused-labels](./no-unused-labels.md)
-
-## Further Reading
-
-* ['{a}' is a statement label](http://jslinterrors.com/a-is-a-statement-label/)

docs/rules/no-mixed-requires.md

@@ -4,10 +4,10 @@ In the Node.JS community it is often customary to separate the `require`d module
 
 ## Rule Details
 
-When this rule is enabled, all `var` statements must satisfy the following conditions:
+When this rule is enabled, each `var` statement must satisfy the following conditions:
 
-* either none or all variable declarations must be require declarations
-* all require declarations must be of the same type (optional)
+* either none or all variable declarations must be require declarations (default)
+* all require declarations must be of the same type (grouping)
 
 This rule distinguishes between six kinds of variable declaration types:
 
@@ -35,21 +35,28 @@ This rule comes with two boolean options. Both are turned off by default. You ca
 
 ```json
 {
-    "no-mixed-requires": [1, {"grouping": true, "allowCall": true}]
+    "no-mixed-requires": [2, {"grouping": true, "allowCall": true}]
 }
 ```
 
-The second way to configure this rule is with boolean (This way of setting is deprecated).
+The second way to configure this rule is with boolean. This way of setting is deprecated.
 
 ```json
 {
-    "no-mixed-requires": [1, true]
+    "no-mixed-requires": [2, true]
 }
 ```
 
 If enabled, violations will be reported whenever a single `var` statement contains require declarations of mixed types (see the examples below).
 
-## Examples
+The following patterns are considered problems:
+
+```js
+/*eslint no-mixed-requires: 2*/
+
+var fs = require('fs'),
+    i = 0;
+```
 
 The following patterns are not considered problems:
 
@@ -72,14 +79,7 @@ var foo = require('foo' + VERSION),
     baz = require();
 ```
 
-The following patterns are considered problems:
-
-```js
-/*eslint no-mixed-requires: 2*/
-
-var fs = require('fs'),
-    i = 0;
-```
+### grouping
 
 The following patterns are considered problems when grouping is turned on:
 
@@ -95,6 +95,8 @@ var foo = require('foo'),
     bar = require(getBarModuleName());
 ```
 
+### allowCall
+
 The following patterns are not considered problems when `allowCall` is turned on:
 
 ```js
@@ -111,14 +113,16 @@ var async = require('async'),
     eslint = require('eslint');
 ```
 
-## When Not To Use It
+## Known Limitations
 
-Internally, the list of core modules is retrieved via `require("repl")._builtinLibs`. If you use different versions of Node.JS for ESLint and your application, the list of core modules for each version may be different.
-The above mentioned `_builtinLibs` property became available in 0.8, for earlier versions a hardcoded list of module names is used as a fallback. If your version of Node is older than 0.6 that list may be inaccurate.
+* The implementation is not aware of any local functions with the name `require` that may shadow Node's global `require`.
 
-If you use a pattern such as [UMD][4] where the `require`d modules are not loaded in variable declarations, this rule will obviously do nothing for you.
+* Internally, the list of core modules is retrieved via `require("repl")._builtinLibs`. If you use different versions of Node.JS for ESLint and your application, the list of core modules for each version may be different.
+  The above mentioned `_builtinLibs` property became available in 0.8, for earlier versions a hardcoded list of module names is used as a fallback. If your version of Node is older than 0.6 that list may be inaccurate.
 
-The implementation is not aware of any local functions with the name `require` that may shadow Node's global `require`.
+## When Not To Use It
+
+If you use a pattern such as [UMD][4] where the `require`d modules are not loaded in variable declarations, this rule will obviously do nothing for you.
 
 [1]: http://nodejs.org/api/modules.html#modules_core_modules
 [2]: http://nodejs.org/api/modules.html#modules_file_modules