Clean up language in the function section.

michaeltwofish · michaeltwofish · commit 9e3e75664e49 · 2012-06-03T14:48:06.000+10:00
diff --git a/doc/en/function/arguments.md b/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.
diff --git a/doc/en/function/closures.md b/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() {
diff --git a/doc/en/function/constructors.md b/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**.
 
diff --git a/doc/en/function/general.md b/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() {}
diff --git a/doc/en/function/scopes.md b/doc/en/function/scopes.md
@@ -73,7 +73,7 @@ unless the *desired effect* is to affect the outer scope.
 ### Local Variables
 
 The only source for local variables in JavaScript are
-[function](#function.general) parameters and variables that were declared via the 
+[function](#function.general) parameters and variables declared via the 
 `var` statement.
 
     // global scope
@@ -115,8 +115,8 @@ JavaScript **hoists** declarations. This means that both `var` statements and
         }
     }
 
-The above code gets transformed before any execution is started. JavaScript moves
-the `var` statements, as well as the `function` declarations to the top of the 
+The above code gets transformed before execution starts. JavaScript moves
+the `var` statements, as well as `function` declarations, to the top of the 
 nearest surrounding scope.
 
     // var statements got moved here
@@ -150,15 +150,15 @@ In the original code, although the `if` statement seemed to modify the *global
 variable* `goo`, it actually modifies the *local variable* - after hoisting 
 has been applied.
 
-Without the knowledge about *hoisting*, the below code might seem to raise a 
+Without knowledge of *hoisting*, one might suspect the code below would raise a
 `ReferenceError`.
 
     // check whether SomeImportantThing has been initialized
     if (!SomeImportantThing) {
         var SomeImportantThing = {};
     }
 
-But of course, the above works due to the fact that the `var` statement is being 
+But of course, this works due to the fact that the `var` statement is being 
 moved to the top of the *global scope*.
 
     var SomeImportantThing;
@@ -176,10 +176,10 @@ All scopes in JavaScript, including the *global scope*, have the special name
 [`this`](#function.this), defined in them, which refers to the *current object*. 
 
 Function scopes also have the name [`arguments`](#function.arguments), defined in
-them, which contains the arguments that were passed to a function.
+them, which contains the arguments that were passed to the function.
 
 For example, when trying to access a variable named `foo` inside the scope of a 
-function, JavaScript will lookup the name in the following order:
+function, JavaScript will look up the name in the following order:
 
  1. In case there is a `var foo` statement in the current scope, use that.
  2. If one of the function parameters is named `foo`, use that.
@@ -191,9 +191,9 @@ function, JavaScript will lookup the name in the following order:
 
 ### Namespaces
 
-A common problem of having only one global namespace is the likeliness of running
-into problems where variable names clash. In JavaScript, this problem can
-easily be avoided with the help of *anonymous wrappers*.
+A common problem associated with having only one global namespace is the
+likelihood of running into problems where variable names clash. In JavaScript,
+this problem can easily be avoided with the help of *anonymous wrappers*.
 
     (function() {
         // a self contained "namespace"
@@ -208,13 +208,13 @@ easily be avoided with the help of *anonymous wrappers*.
 Unnamed functions are considered [expressions](#function.general); so in order to
 being callable, they must first be evaluated.
 
-    ( // evaluate the function inside the paranthesis
+    ( // evaluate the function inside the parentheses
     function() {}
     ) // and return the function object
     () // call the result of the evaluation
 
-There are other ways for evaluating and directly calling the function expression; which, 
-while different in syntax, do behave the exact same way.
+There are other ways to evaluate and directly call the function expression
+which, while different in syntax, behave the same way.
 
     // A few other styles for directly invoking the 
     !function(){}()
@@ -224,7 +224,7 @@ while different in syntax, do behave the exact same way.
 
 ### In Conclusion
 
-It is recommended to always use an *anonymous wrapper* for encapsulating code in 
+It is recommended to always use an *anonymous wrapper* to encapsulate code in 
 its own namespace. This does not only protect code against name clashes, but it 
 also allows for better modularization of programs.
 
diff --git a/doc/en/function/this.md b/doc/en/function/this.md
@@ -1,7 +1,7 @@
 ## How `this` Works
 
 JavaScript has a different concept of what the special name `this` refers to 
-than most other programming languages do. There are exactly **five** different 
+than most other programming languages. There are exactly **five** different 
 ways in which the value of `this` can be bound in the language.
 
 ### The Global Scope
@@ -55,7 +55,7 @@ inside of `foo` will be set to `bar`.
 
 ### Common Pitfalls
 
-While most of these cases make sense, the first one is to be considered another
+While most of these cases make sense, the first can be considered another
 mis-design of the language because it **never** has any practical use.
 
     Foo.method = function() {
@@ -69,7 +69,7 @@ A common misconception is that `this` inside of `test` refers to `Foo`; while in
 fact, it **does not**.
 
 In order to gain access to `Foo` from within `test`, it is necessary to create a 
-local variable inside of `method` which refers to `Foo`.
+local variable inside of `method` that refers to `Foo`.
 
     Foo.method = function() {
         var that = this;
@@ -105,7 +105,7 @@ fact, it is what makes [prototypal inheritance](#object.prototype) work.
 
     new Bar().method();
 
-When `method` gets called on a instance of `Bar`, `this` will now refer to that
+When `method` gets called on an instance of `Bar`, `this` will now refer to that
 very instance. 
 
 
