Skip to content

Commit 9e3e756

Browse files
Clean up language in the function section.
1 parent 5c5295d commit 9e3e756

File tree

6 files changed

+43
-44
lines changed

6 files changed

+43
-44
lines changed

doc/en/function/arguments.md

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -79,9 +79,9 @@ of the corresponding property on the `arguments` object, and the other way aroun
7979

8080
### Performance Myths and Truths
8181

82-
The `arguments` object is always created with the only two exceptions being the
83-
cases where it is declared as a name inside of a function or one of its formal
84-
parameters. It does not matter whether it is used or not.
82+
The only time the `arguments` object is not created is where it is declared as
83+
a name inside of a function or one of its formal parameters. It does not matter
84+
whether it is used or not.
8585

8686
Both *getters* and *setters* are **always** created; thus, using it has nearly
8787
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
108108
performance gains that would arise from inlining, but it also breaks encapsulation
109109
because the function may now be dependent on a specific calling context.
110110

111-
It is **highly recommended** to **never** make use of `arguments.callee` or any of
112-
its properties.
111+
Making use of `arguments.callee` or any of its properties is **highly discouraged**.
113112

114113
> **ES5 Note:** In strict mode, `arguments.callee` will throw a `TypeError` since
115114
> its use has been deprecated.

doc/en/function/closures.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ were defined. Since the only scoping that JavaScript has is
2727
Here, `Counter` returns **two** closures: the function `increment` as well as
2828
the function `get`. Both of these functions keep a **reference** to the scope of
2929
`Counter` and, therefore, always keep access to the `count` variable that was
30-
defined in that very scope.
30+
defined in that scope.
3131

3232
### Why Private Variables Work
3333

@@ -47,7 +47,7 @@ override - the *global* variable `count`.
4747
### Closures Inside Loops
4848

4949
One often made mistake is to use closures inside of loops, as if they were
50-
copying the value of the loops index variable.
50+
copying the value of the loop's index variable.
5151

5252
for(var i = 0; i < 10; i++) {
5353
setTimeout(function() {

doc/en/function/constructors.md

Lines changed: 16 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ The above calls `Foo` as constructor and sets the `prototype` of the newly
2525
created object to `Foo.prototype`.
2626

2727
In case of an explicit `return` statement, the function returns the value
28-
specified that statement, **but only** if the return value is an `Object`.
28+
specified by that statement, but **only** if the return value is an `Object`.
2929

3030
function Bar() {
3131
return 2;
@@ -72,24 +72,24 @@ explicitly return a value.
7272
new Bar();
7373
Bar();
7474

75-
Both calls to `Bar` return the exact same thing, a newly create object which
76-
has a property called `method` on it, which is a
75+
Both calls to `Bar` return the same thing, a newly create object that
76+
has a property called `method`, which is a
7777
[Closure](#function.closures).
7878

79-
It is also to note that the call `new Bar()` does **not** affect the prototype
80-
of the returned object. While the prototype will be set on the newly created
81-
object, `Bar` never returns that new object.
79+
It should also be noted that the call `new Bar()` does **not** affect the
80+
prototype of the returned object. While the prototype will be set on the newly
81+
created object, `Bar` never returns that new object.
8282

8383
In the above example, there is no functional difference between using and
8484
not using the `new` keyword.
8585

8686

8787
### Creating New Objects via Factories
8888

89-
An often made recommendation is to **not** use `new` because forgetting its use
90-
may lead to bugs.
89+
It is often recommended to **not** use `new` because forgetting its use may
90+
lead to bugs.
9191

92-
In order to create new object, one should rather use a factory and construct a
92+
In order to create a new object, one should rather use a factory and construct a
9393
new object inside of that factory.
9494

9595
function Foo() {
@@ -113,16 +113,16 @@ downsides.
113113

114114
1. It uses more memory since the created objects do **not** share the methods
115115
on a prototype.
116-
2. In order to inherit the factory needs to copy all the methods from another
116+
2. In order to inherit, the factory needs to copy all the methods from another
117117
object or put that object on the prototype of the new object.
118118
3. Dropping the prototype chain just because of a left out `new` keyword
119-
somehow goes against the spirit of the language.
119+
is contrary to the spirit of the language.
120120

121121
### In Conclusion
122122

123-
While omitting the `new` keyword might lead to bugs, it is certainly **not** a
124-
reason to drop the use of prototypes altogether. In the end it comes down to
125-
which solution is better suited for the needs of the application, it is
126-
especially important to choose a specific style of object creation **and stick**
127-
with it.
123+
While omitting the `new` keyword might lead to bugs, it is certainly **not** a
124+
reason to drop the use of prototypes altogether. In the end it comes down to
125+
which solution is better suited for the needs of the application. It is
126+
especially important to choose a specific style of object creation and use it
127+
**consistently**.
128128

doc/en/function/general.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,9 +8,9 @@ an *anonymous function* as a callback to another, possibly an asynchronous funct
88

99
function foo() {}
1010

11-
The above function gets [hoisted](#function.scopes) before the execution of the
12-
program starts; thus, it is available *everywhere* in the scope it was *defined*
13-
in, even if called before the actual definition in the source.
11+
The above function gets [hoisted](#function.scopes) before the execution of the
12+
program starts; thus, it is available *everywhere* in the scope it was
13+
*defined*, even if called before the actual definition in the source.
1414

1515
foo(); // Works because foo was created before this code runs
1616
function foo() {}

doc/en/function/scopes.md

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -73,7 +73,7 @@ unless the *desired effect* is to affect the outer scope.
7373
### Local Variables
7474

7575
The only source for local variables in JavaScript are
76-
[function](#function.general) parameters and variables that were declared via the
76+
[function](#function.general) parameters and variables declared via the
7777
`var` statement.
7878

7979
// global scope
@@ -115,8 +115,8 @@ JavaScript **hoists** declarations. This means that both `var` statements and
115115
}
116116
}
117117

118-
The above code gets transformed before any execution is started. JavaScript moves
119-
the `var` statements, as well as the `function` declarations to the top of the
118+
The above code gets transformed before execution starts. JavaScript moves
119+
the `var` statements, as well as `function` declarations, to the top of the
120120
nearest surrounding scope.
121121

122122
// var statements got moved here
@@ -150,15 +150,15 @@ In the original code, although the `if` statement seemed to modify the *global
150150
variable* `goo`, it actually modifies the *local variable* - after hoisting
151151
has been applied.
152152

153-
Without the knowledge about *hoisting*, the below code might seem to raise a
153+
Without knowledge of *hoisting*, one might suspect the code below would raise a
154154
`ReferenceError`.
155155

156156
// check whether SomeImportantThing has been initialized
157157
if (!SomeImportantThing) {
158158
var SomeImportantThing = {};
159159
}
160160

161-
But of course, the above works due to the fact that the `var` statement is being
161+
But of course, this works due to the fact that the `var` statement is being
162162
moved to the top of the *global scope*.
163163

164164
var SomeImportantThing;
@@ -176,10 +176,10 @@ All scopes in JavaScript, including the *global scope*, have the special name
176176
[`this`](#function.this), defined in them, which refers to the *current object*.
177177

178178
Function scopes also have the name [`arguments`](#function.arguments), defined in
179-
them, which contains the arguments that were passed to a function.
179+
them, which contains the arguments that were passed to the function.
180180

181181
For example, when trying to access a variable named `foo` inside the scope of a
182-
function, JavaScript will lookup the name in the following order:
182+
function, JavaScript will look up the name in the following order:
183183

184184
1. In case there is a `var foo` statement in the current scope, use that.
185185
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:
191191
192192
### Namespaces
193193

194-
A common problem of having only one global namespace is the likeliness of running
195-
into problems where variable names clash. In JavaScript, this problem can
196-
easily be avoided with the help of *anonymous wrappers*.
194+
A common problem associated with having only one global namespace is the
195+
likelihood of running into problems where variable names clash. In JavaScript,
196+
this problem can easily be avoided with the help of *anonymous wrappers*.
197197

198198
(function() {
199199
// a self contained "namespace"
@@ -208,13 +208,13 @@ easily be avoided with the help of *anonymous wrappers*.
208208
Unnamed functions are considered [expressions](#function.general); so in order to
209209
being callable, they must first be evaluated.
210210

211-
( // evaluate the function inside the paranthesis
211+
( // evaluate the function inside the parentheses
212212
function() {}
213213
) // and return the function object
214214
() // call the result of the evaluation
215215

216-
There are other ways for evaluating and directly calling the function expression; which,
217-
while different in syntax, do behave the exact same way.
216+
There are other ways to evaluate and directly call the function expression
217+
which, while different in syntax, behave the same way.
218218

219219
// A few other styles for directly invoking the
220220
!function(){}()
@@ -224,7 +224,7 @@ while different in syntax, do behave the exact same way.
224224

225225
### In Conclusion
226226

227-
It is recommended to always use an *anonymous wrapper* for encapsulating code in
227+
It is recommended to always use an *anonymous wrapper* to encapsulate code in
228228
its own namespace. This does not only protect code against name clashes, but it
229229
also allows for better modularization of programs.
230230

doc/en/function/this.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
## How `this` Works
22

33
JavaScript has a different concept of what the special name `this` refers to
4-
than most other programming languages do. There are exactly **five** different
4+
than most other programming languages. There are exactly **five** different
55
ways in which the value of `this` can be bound in the language.
66

77
### The Global Scope
@@ -55,7 +55,7 @@ inside of `foo` will be set to `bar`.
5555
5656
### Common Pitfalls
5757

58-
While most of these cases make sense, the first one is to be considered another
58+
While most of these cases make sense, the first can be considered another
5959
mis-design of the language because it **never** has any practical use.
6060

6161
Foo.method = function() {
@@ -69,7 +69,7 @@ A common misconception is that `this` inside of `test` refers to `Foo`; while in
6969
fact, it **does not**.
7070

7171
In order to gain access to `Foo` from within `test`, it is necessary to create a
72-
local variable inside of `method` which refers to `Foo`.
72+
local variable inside of `method` that refers to `Foo`.
7373

7474
Foo.method = function() {
7575
var that = this;
@@ -105,7 +105,7 @@ fact, it is what makes [prototypal inheritance](#object.prototype) work.
105105

106106
new Bar().method();
107107

108-
When `method` gets called on a instance of `Bar`, `this` will now refer to that
108+
When `method` gets called on an instance of `Bar`, `this` will now refer to that
109109
very instance.
110110

111111

0 commit comments

Comments
 (0)