Merge in typo fixes by michaeltwofish

doc/en/array/constructor.md

@@ -21,15 +21,15 @@ the actual indexes of the array will not be initialized.
     arr[1]; // undefined
     1 in arr; // false, the index was not set
 
-The behavior of being able to set the length of the array upfront only comes in 
-handy in a few cases, like repeating a string, in which it avoids the use of a 
-`for loop` code.
+Being able to set the length of the array in advance is only useful in a few
+cases, like repeating a string, in which it avoids the use of a `for loop`
+code.
 
     new Array(count + 1).join(stringToRepeat);
 
 ### In Conclusion
 
-The use of the `Array` constructor should be avoided as much as possible. 
-Literals are definitely preferred. They are shorter and have a clearer syntax; 
-therefore, they also increase the readability of the code.
+The use of the `Array` constructor should be avoided. Literals are definitely
+preferred. They are shorter, have a clearer syntax, and increase code
+readability.
 

doc/en/core/delete.md

@@ -5,12 +5,11 @@ stuff in JavaScript which have a `DontDelete` attribute set.
 
 ### Global code and Function code
 
-When a variable or a function is defined in a global 
-or a [function scope](#function.scopes) it is a property of either 
-Activation object or Global object. Such properties have a set of attributes, 
-one of these is `DontDelete`. Variable and function declarations in global 
-and function code always create properties with `DontDelete`, therefore 
-cannot be deleted.
+When a variable or a function is defined in a global or a [function
+scope](#function.scopes) it is a property of either the Activation object or
+the Global object. Such properties have a set of attributes, one of which is
+`DontDelete`. Variable and function declarations in global and function code
+always create properties with `DontDelete`, and therefore cannot be deleted.
 
     // global variable:
     var a = 1; // DontDelete is set
@@ -29,8 +28,7 @@ cannot be deleted.
 
 ### Explicit properties
 
-There are things which can be deleted normally: these are explicitly set 
-properties.
+Explicitly set properties can be deleted normally.
 
     // explicitly set property:
     var obj = {x: 1};
@@ -40,8 +38,8 @@ properties.
     obj.x; // undefined
     obj.y; // undefined
 
-In the example above `obj.x` and `obj.y` can be deleted because they have no 
-`DontDelete` atribute. That's why an example below works too.
+In the example above, `obj.x` and `obj.y` can be deleted because they have no 
+`DontDelete` atribute. That's why the example below works too.
 
     // this works fine, except for IE:
     var GLOBAL_OBJECT = this;
@@ -58,7 +56,7 @@ IE (at least 6-8) has some bugs, so the code above doesn't work.
 
 ### Function arguments and built-ins
 
-Functions' normal arguments, [`arguments` object](#function.arguments) 
+Functions' normal arguments, [`arguments` objects](#function.arguments) 
 and built-in properties also have `DontDelete` set.
 
     // function arguments and properties:
@@ -78,10 +76,10 @@ and built-in properties also have `DontDelete` set.
 
 ### Host objects
 
-Behaviour of `delete` operator can be unpredictable for hosted objects. Due to 
-specification, host objects are allowed to implement any kind of behavior. 
+The behaviour of `delete` operator can be unpredictable for hosted objects. Due
+to the specification, host objects are allowed to implement any kind of behavior. 
 
 ### In conclusion
 
-`delete` operator often has an unexpected behaviour and can be safely used 
-only for dealing with explicitly set properties on normal objects.
+The `delete` operator often has unexpected behaviour and can only be safely
+used to delete explicitly set properties on normal objects.

doc/en/core/eval.md

@@ -12,7 +12,7 @@ The `eval` function will execute a string of JavaScript code in the local scope.
     foo; // 1
 
 However, `eval` only executes in the local scope when it is being called
-**directly** *and* when the name of the called function is actually `eval`.
+directly *and* when the name of the called function is actually `eval`.
 
     var foo = 1;
     function test() {
@@ -24,8 +24,8 @@ However, `eval` only executes in the local scope when it is being called
     test(); // 2
     foo; // 3
 
-The use of `eval` should be avoided at **all costs**. 99.9% of its "uses" can be
-achieved **without** it.
+The use of `eval` should be avoided. 99.9% of its "uses" can be achieved
+**without** it.
 
 ### `eval` in Disguise
 
@@ -35,13 +35,13 @@ in the global scope since `eval` is not being called directly in that case.
 
 ### Security Issues
 
-`eval` also is a security problem. Because it executes **any** code given to it,
-it should **never** be used with strings of unknown or untrusted origins.
+`eval` also is a security problem, because it executes **any** code given to it.
+It should **never** be used with strings of unknown or untrusted origins.
 
 ### In Conclusion
 
-`eval` should never be used. Any code that makes use of it is to be questioned in
-its workings, performance and security. In case something requires `eval` in 
-order to work, it should **not** be used in the first place.
-A *better design* should be used, that does not require the use of `eval`.
+`eval` should never be used. Any code that makes use of it should be questioned
+in its workings, performance and security. If something requires `eval` in
+order to work, it should **not** be used in the first place.  A *better design*
+should be used, that does not require the use of `eval`.
 

doc/en/core/semicolon.md

@@ -84,7 +84,7 @@ Below is the result of the parser's "guessing" game.
     })(window); //<- inserted
 
 > **Note:** The JavaScript parser does not "correctly" handle return statements 
-> which are followed by a new line, while this is not neccessarily the fault of 
+> that are followed by a new line. While this is not neccessarily the fault of 
 > the automatic semicolon insertion, it can still be an unwanted side-effect. 
 
 The parser drastically changed the behavior of the code above. In certain cases,
@@ -106,9 +106,9 @@ the above will yield a `TypeError` stating that `undefined is not a function`.
 
 ### In Conclusion
 
-It is highly recommended to **never** omit semicolons; it is also advocated to 
-keep braces on the same line with their corresponding statements and to never omit 
-them for one single-line `if` / `else` statements. Both of these measures will 
-not only improve the consistency of the code, but they will also prevent the 
-JavaScript parser from changing its behavior.
+It is highly recommended to **never** omit semicolons. It is also recommended
+that braces be kept on the same line as their corresponding statements and to
+never omit them for single-line `if` / `else` statements. These measures will
+not only improve the consistency of the code, but they will also prevent the
+JavaScript parser from changing code behavior.
 

doc/en/core/undefined.md

@@ -1,7 +1,7 @@
 ## `undefined` and `null`
 
-JavaScript has two distinct values for `nothing`, the more useful of these two
-being `undefined`.
+JavaScript has two distinct values for nothing, `null` and `undefined`, with
+the latter being more useful.
 
 ### The Value `undefined`
 
@@ -16,14 +16,14 @@ overwritten.
 > mode, but its name can still be shadowed by for example a function with the name 
 > `undefined`.
 
-Some examples for when the value `undefined` is returned:
+Here are some examples of when the value `undefined` is returned:
 
  - Accessing the (unmodified) global variable `undefined`.
- - Accessing a declared *but not* yet initialized variable
+ - Accessing a declared *but not* yet initialized variable.
  - Implicit returns of functions due to missing `return` statements.
- - `return` statements which do not explicitly return anything.
+ - `return` statements that do not explicitly return anything.
  - Lookups of non-existent properties.
- - Function parameters which do not had any explicit value passed.
+ - Function parameters that do not have any explicit value passed.
  - Anything that has been set to the value of `undefined`.
  - Any expression in the form of `void(expression)`
 
@@ -36,14 +36,14 @@ Since the global variable `undefined` only holds a copy of the actual *value* of
 Still, in order to compare something against the value of `undefined`, it is
 necessary to retrieve the value of `undefined` first.
 
-In order to protect code against a possible overwritten `undefined` variable, a 
-common technique used is to add an additional parameter to an
-[anonymous wrapper](#function.scopes) that gets no argument passed to it.
+To protect code against a possible overwritten `undefined` variable, a common
+technique used is to add an additional parameter to an [anonymous
+wrapper](#function.scopes) that gets no argument passed to it.
 
     var undefined = 123;
     (function(something, foo, undefined) {
         // undefined in the local scope does 
-        // now again refer to the value
+        // now again refer to the value `undefined`
 
     })('Hello World', 42);
 

doc/en/function/arguments.md

@@ -79,9 +79,9 @@ of the corresponding property on the `arguments` object, and the other way aroun
 
 ### Performance Myths and Truths
 
-The `arguments` object is always created with the only two exceptions being the 
-cases where it is declared as a name inside of a function or one of its formal 
-parameters. It does not matter whether it is used or not.
+The only time  the `arguments` object is not created is where it is declared as
+a name inside of a function or one of its formal parameters. It does not matter
+whether it is used or not.
 
 Both *getters* and *setters* are **always** created; thus, using it has nearly 
 no performance impact at all, especially not in real world code where there is 
@@ -108,8 +108,7 @@ needs to know about both itself and its caller. This not only defeats possible
 performance gains that would arise from inlining, but it also breaks encapsulation
 because the function may now be dependent on a specific calling context.
 
-It is **highly recommended** to **never** make use of `arguments.callee` or any of 
-its properties.
+Making use of `arguments.callee` or any of its properties is **highly discouraged**.
 
 > **ES5 Note:** In strict mode, `arguments.callee` will throw a `TypeError` since 
 > its use has been deprecated.

doc/en/function/closures.md

@@ -27,7 +27,7 @@ were defined. Since the only scoping that JavaScript has is
 Here, `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 keep access to the `count` variable that was 
-defined in that very scope.
+defined in that scope.
 
 ### Why Private Variables Work
 
@@ -47,7 +47,7 @@ override - the *global* variable `count`.
 ### Closures Inside Loops
 
 One often made mistake is to use closures inside of loops, as if they were
-copying the value of the loops index variable.
+copying the value of the loop's index variable.
 
     for(var i = 0; i < 10; i++) {
         setTimeout(function() {

doc/en/function/constructors.md

@@ -25,7 +25,7 @@ The above calls `Foo` as constructor and sets the `prototype` of the newly
 created object to `Foo.prototype`.
 
 In case of an explicit `return` statement, the function returns the value 
-specified that statement, **but only** if the return value is an `Object`.                                     
+specified by that statement, but **only** if the return value is an `Object`.
 
     function Bar() {
         return 2;
@@ -72,24 +72,24 @@ explicitly return a value.
     new Bar();
     Bar();
 
-Both calls to `Bar` return the exact same thing, a newly create object which
-has a property called `method` on it, which is a 
+Both calls to `Bar` return the same thing, a newly create object that
+has a property called `method`, which is a 
 [Closure](#function.closures).
 
-It is also to note that the call `new Bar()` does **not** affect the prototype 
-of the returned object. While the prototype will be set on the newly created 
-object, `Bar` never returns that new object.
+It should also be noted that the call `new Bar()` does **not** affect the
+prototype of the returned object. While the prototype will be set on the newly
+created object, `Bar` never returns that new object.
 
 In the above example, there is no functional difference between using and
 not using the `new` keyword.
 
 
 ### Creating New Objects via Factories
 
-An often made recommendation is to **not** use `new` because forgetting its use
-may lead to bugs.
+It is often recommended to **not** use `new` because forgetting its use may
+lead to bugs.
 
-In order to create new object, one should rather use a factory and construct a 
+In order to create a new object, one should rather use a factory and construct a 
 new object inside of that factory.
 
     function Foo() {
@@ -113,16 +113,16 @@ downsides.
 
  1. It uses more memory since the created objects do **not** share the methods
     on a prototype.
- 2. In order to inherit the factory needs to copy all the methods from another
+ 2. In order to inherit, the factory needs to copy all the methods from another
     object or put that object on the prototype of the new object.
  3. Dropping the prototype chain just because of a left out `new` keyword
-    somehow goes against the spirit of the language.
+    is contrary to the spirit of the language.
 
 ### In Conclusion
 
-While omitting the `new` keyword might lead to bugs, it is certainly **not** a 
-reason to drop the use of prototypes altogether. In the end it comes down to 
-which solution is better suited for the needs of the application, it is 
-especially important to choose a specific style of object creation **and stick** 
-with it.
+While omitting the `new` keyword might lead to bugs, it is certainly **not** a
+reason to drop the use of prototypes altogether. In the end it comes down to
+which solution is better suited for the needs of the application. It is
+especially important to choose a specific style of object creation and use it
+**consistently**.
 

doc/en/function/general.md

@@ -8,9 +8,9 @@ an *anonymous function* as a callback to another, possibly an asynchronous funct
 
     function foo() {}
 
-The above function gets [hoisted](#function.scopes) 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.
+The above function gets [hoisted](#function.scopes) before the execution of the
+program starts; thus, it is available *everywhere* in the scope it was
+*defined*, even if called before the actual definition in the source.
 
     foo(); // Works because foo was created before this code runs
     function foo() {}