Do some grammatic cleanup

Author: BonsaiDen

doc/arrayctor.md

@@ -22,6 +22,6 @@ which it avoids the use of a `for` loop.
 ### In conclusion
 
 The use of the `Array` constructor should be avoided as much as possible. The `[]` 
-notation is definitely preferred. It is shorter and has a clear syntax, and is
-therefore increasing the readability of code and helps to avoid subtle mistakes.
+notation is definitely preferred. It is shorter and has a clearer syntax; thus, 
+it also  increases the readability of code.
 

doc/closures.md

@@ -27,7 +27,7 @@ defined in. Since the only scope that JavaScript has is the
 
 In the above example `Counter` returns **two** closures. The function `increment`
 as well as the function `get`. Both of these functions keep a **reference** to 
-the scope of `Counter` and therefore always have access to the `count` variable 
+the scope of `Counter` and, therefore, always have access to the `count` variable 
 that was defined in that **very** scope.
 
 ### Why private variables work
@@ -81,8 +81,7 @@ In order to copy the value of the loop its index variable, it is best to use an
     }
 
 The anonymous outer function gets called immediately with `i` as the first 
-argument, therefore it will receive a copy of the **value** of `i` as its 
-parameter `e`.
+argument and will receive a copy of the **value** of `i` as its parameter `e`.
 
 The anonymous function that gets passed to `setTimeout` now has a reference to 
 `e`, which value does **not** get changed by the loop.

doc/equality.md

@@ -24,9 +24,9 @@ The above table shows the results of the type coercion and it is the main reason
 why the use of `==` is regarded as bad practice, it introduces hard to track down
 bugs due to its complicated conversion rules.
 
-Additionally there is also a performance impact when type coercion is in play,
-since for example a string has to be converted to a number before the comparison
-is done. 
+Additionally there is also a performance impact when type coercion is in play;
+for example, a string has to be converted to a number before it can be compared
+with another number.
 
 ### The strict equals operator
 

doc/forinloop.md

@@ -4,7 +4,7 @@ Just like the `in` operator, the `for in` loop also traverses the prototype
 chain when iterating over the properties of an object.
 
 > **Note:** The `for in` loop will **not** iterate over any properties that 
-> have their `enumerable` attribute set to `false`, for example the `length` 
+> have their `enumerable` attribute set to `false`; for example, the `length` 
 > property of an array.
     
     // Poisoning Object.prototype
@@ -34,8 +34,8 @@ object.
 
 This version is the only correct one to use. Due to the use of `hasOwnPropery` it
 will **only** print out `moo`. When `hasOwnProperty` is left out, the code is 
-prone to errors when the native prototypes - for example `Object.prototype` - 
-have been extended.
+prone to errors when the native prototypes have been extended; for example,
+`Object.prototype`.
 
 One widely used framework which does this is [**Prototype**][1]. When this 
 framework is included, `for in` loops that doe not use `hasOwnProperty` are 

doc/functions.md

@@ -8,9 +8,9 @@ passed around like any other value. One common use of this feature is to pass
 
     function foo() {}
 
-The above function gets created **before** the execution of the program starts.
-Therefore it is available everywhere in the scope it was *defined* in, even if it
-is called before its actual definition in the source.
+The above function gets created **before** the execution of the program starts;
+thus, it is available *everywhere* in the scope it was *defined* in, even if 
+called before the actual definition in the source.
 
     foo(); // Works because foo was created before this code runs
     function foo() {}
@@ -19,8 +19,8 @@ is called before its actual definition in the source.
 
     var foo = function() {};
 
-The above assigns the unnamed and therefore *anonymous* function, to the variable
-`foo`. 
+The above assigns the unnamed and, therefore, *anonymous* function, to the 
+variable `foo`. 
 
     foo; // 'undefined'
     foo(); // this raises a TypeError
@@ -72,7 +72,7 @@ Also, while the statements inside the `if` block never get executed, the variabl
 
 ### `var` vs. `function`
 
-All `var` statements get parsed **before** `function` statements, therefore 
+All `var` statements get parsed **before** `function` statements; hence,
 subsequent statements will override the previous ones.
 
     function foo() {}

doc/instanceof.md

@@ -21,9 +21,8 @@ returns a mess similar to the [typeof operator](#typeof).
     'foo' instanceof Object; // false
 
 One important thing to note is that `instanceof` does of course not work on
-objects that origin from different JavaScript contexts. For example: Different
+objects that origin from different JavaScript contexts;rFor example, different
 documents in a web browser.
-a Web Browser.
 
 ### In conclusion
 

doc/objects.md

@@ -66,8 +66,8 @@ the use of property names that would otherwise lead to a syntax error.
 Object properties can be both notated as plain characters and as strings. Due to
 another mis-design in JavaScript's parser, the above raises a `SyntaxError`.
 
-The error is getting raised because `delete` is a *keyword* of the language, 
-therefore it must be, just like `case`, notated as a string literal.
+The error is getting raised because `delete` is a *keyword* of the language;
+therefore, it must be notated as a string literal.
 
 ### In conclusion
 

doc/prototype.md

@@ -36,15 +36,15 @@ The first major difference is that inheritance in JavaScript is done by using
                 Bar.method()
 
 The above object `test` will inherit from both `Bar.prototype` and
-`Foo.prototype`. It will therefore have access to the function `method` that was 
+`Foo.prototype`. Hence, it will have access to the function `method` that was 
 defined on `Foo`, but it will not have access to the **property** `value` of a 
 `Foo` instance since that property gets defined in the [constructor](#constructor)
 of `Foo`. Which, in this case, never gets called.
 
 > **Note:** Do **not** use `Bar.property = Foo`, since it will not point to 
-> the prototype of `Foo` but rather to the function object `Foo`. Therefore the 
-> prototype chain will go over `Function.prototype` in this case, which results
-> in `method` not being on the prototype chain.
+> the prototype of `Foo` but rather to the function object `Foo`. Because of
+> that, the prototype chain will go over `Function.prototype`, which results
+> in `method` not being on it.
 
 ### Property lookup
 
@@ -86,9 +86,9 @@ chains.
                 Bar.prototype: [Foo Instance]
                     Bar.method()
 
-Now `Bar.prototype` points to an *instance* of `Foo`, therefore the property
-`value` of **that** instance is now on the prototype chain and since `Foo` itself
-has a prototype, the chain continues with that one afterwards.
+Now `Bar.prototype` points to an *instance* of `Foo`; thus, the property
+`value` of that very instance is now on the prototype chain. And since `Foo` 
+itself has a prototype, the chain continues with that one afterwards.
 
 ### Performance
 
@@ -110,7 +110,7 @@ is still no good reason for cluttering built in types with additional
 non-standard functionality.
 
 The **only** good reason for extending a built in prototype is to back port 
-the features of newer JavaScript engines to older ones, like for example
+the features of newer JavaScript engines to older ones; for example, 
 [`Array.forEach`][3].
 
 ### In conclusion

doc/scopes.md

@@ -1,8 +1,8 @@
 ## Scopes and Namespaces
 
 Although JavaScript deals fine with the block scope syntax of two matching curly
-braces, it does **not** support block scope. Therefore all that's left is *function
-scope*.
+braces, it does **not** support block scope; thus, all that is left is the 
+*function scope*.
 
 > **Note:** When not used in an assignment or as a function argument, the `{...}`
 > notation will get interpreted as a block statement and **not** as an `Object`. 
@@ -44,8 +44,6 @@ Leaving out the `var` statement will override the value of `foo`, this might not
 seem like a big deal at first, but consider having a ten-thousand line
 JavaScript file with lots and lots of different variable names, not using `var`
 will introduce hard to track down bugs.
-
-For example, when using generic variable names like `i` in loops.
 
     // global scope
     var items = [/* some list */];
@@ -62,8 +60,8 @@ For example, when using generic variable names like `i` in loops.
 
 The outer loop will terminate after the first call to `subLoop` since that
 function overwrites the global value of `i`. Using a `var` for the second
-`for` loop would have easily avoided this error, therefore `var` should never be
-left out unless the desired effect **is** to affect the outer scope.
+`for` loop would have easily avoided this error. The `var` statement should never
+be left out unless the desired effect **is** to affect the outer scope.
 
 ### Local variables
 

doc/this.md

@@ -87,10 +87,10 @@ reference to a variable.
     var test = someObject.methodTest();
     test();
 
-Again due to the first case, `test` now acts like like a plain function call and 
-therefore the `this` inside it will no longer refer to `someObject`.
+Again due to the first case `test` now acts like like a plain function call;
+therefore, `this` inside it will no longer refer to `someObject`.
 
-While the late binding of `this` might seem like a bad thing, it is fact what
+While the late binding of `this` might seem like a bad idea, it is in fact what
 makes [prototypical inheritance](#prototype) work. 
 
     function Foo() {}

doc/timeouts.md

@@ -94,11 +94,11 @@ it is necessary to use brute force in order to achieve this functionality.
         clearTimeout(i);
     }
 
-There might still be timeouts that are unaffected by this arbitrary number, it
-is therefore recommended to keep track of all the timeouts and intervals IDs
-instead.
+There might still be timeouts that are unaffected by this arbitrary number;
+therefore, is is instead recommended to keep track of all the timeout IDs, so
+they can be cleared one by one.
 
-### Things to avoid at all costs
+### Hidden `eval` magic
 
 `setTimeout` and `setInterval` can also take a string as their first parameter.
 This feature should **never** be used, since it internally makes use of `eval`.
@@ -116,8 +116,8 @@ This feature should **never** be used, since it internally makes use of `eval`.
     bar();
 
 Since `eval` is not getting [called directly](#eval) here, the string passed to
-`setTimeout` will get executed in the global scope and will therefore not use 
-the local `foo` of `bar`.
+`setTimeout` will get executed in the global scope; thus, it will not use the 
+local variable `foo` from the scope of `bar`.
 
 It is further recommended to **not** use a string to pass arguments to the
 function that will get called. 

doc/typeof.md

@@ -36,9 +36,9 @@ you can see this is anything but consistent.
 
 The *Class* refers to the value of the internal `[[Class]]` property of an object.
 
-> **From the Specification:**  *Class* can be one of the following values: 
-> `"Arguments"`, `"Array"`, `"Boolean"`, `"Date"`, `"Error"`, `"Function"`,
-> `"JSON"`, `"Math"`, `"Number"`, `"Object"`, `"RegExp"`, `"String"`
+> **From the Specification:** The value of `[[Class]]` can be one of the
+> following strings. `Arguments`, `Array`, `Boolean`, `Date`, `Error`, 
+> `Function`, `JSON`, `Math`, `Number`, `Object`, `RegExp`, `String`.
 
 In order to retrieve the value of *Class* one can has to make use of the
 `toString` method of `Object`.
@@ -69,10 +69,10 @@ referencing it would result in a `ReferenceError`. This is the only thing
 ### In conclusion
 
 In order to check the type of an object, it is highly recommended to use 
-`Object.prototype.toString`, as it is the only reliable way of doing so. 
-As shown in the type table, some return values of `typeof` are not defined in the
-specification and can therefore differ in various implementations.
+`Object.prototype.toString`; as this is the only reliable way of doing so. 
+As shown in the above type table, some return values of `typeof` are not defined 
+in the specification; thus, the can across various implementations.
 
-Unless checking for a variable to be defined, `typeof` should be avoided at
+Unless checking whether a variable is defined, `typeof` should be avoided at
 **all costs**.