Clean up language in the core section.

Author: michaeltwofish

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);