grammar, usage, punctuation edits, Part 1, sections 2.9 - 2.16
This commit is contained in:
parent
e3b35f852a
commit
6006abdfdc
8 changed files with 88 additions and 88 deletions
|
@ -45,7 +45,7 @@ The call `showMessage()` executes the code of the function. Here we will see the
|
|||
|
||||
This example clearly demonstrates one of the main purposes of functions: to evade code duplication.
|
||||
|
||||
If we ever need to change the message or the way it is shown -- it's enough to modify the code in one place: the function which outputs it.
|
||||
If we ever need to change the message or the way it is shown, it's enough to modify the code in one place: the function which outputs it.
|
||||
|
||||
## Local variables
|
||||
|
||||
|
@ -105,7 +105,7 @@ alert( userName ); // *!*Bob*/!*, the value was modified by the function
|
|||
|
||||
The outer variable is only used if there's no local one. So an occasional modification may happen if we forget `let`.
|
||||
|
||||
If a same-named variable is declared inside the function then it *shadows* the outer one. For instance, in the code below the function uses the local `userName`, the outer one is ignored:
|
||||
If a same-named variable is declared inside the function then it *shadows* the outer one. For instance, in the code below the function uses the local `userName`. The outer one is ignored:
|
||||
|
||||
```js run
|
||||
let userName = 'John';
|
||||
|
@ -130,12 +130,12 @@ Variables declared outside of any function, such as the outer `userName` in the
|
|||
|
||||
Global variables are visible from any function (unless shadowed by locals).
|
||||
|
||||
Usually, a function declares all variables specific to its task, and global variables only store project-level data, so important that it really must be seen from anywhere. Modern code has few or no globals, most variables reside in their functions.
|
||||
Usually, a function declares all variables specific to its task, and global variables only store project-level data, so important that it really must be seen from anywhere. Modern code has few or no globals. Most variables reside in their functions.
|
||||
```
|
||||
|
||||
## Parameters
|
||||
|
||||
We can pass arbitrary data to function using parameters (also called *function arguments*) .
|
||||
We can pass arbitrary data to functions using parameters (also called *function arguments*) .
|
||||
|
||||
In the example below, the function has two parameters: `from` and `text`.
|
||||
|
||||
|
@ -183,7 +183,7 @@ For instance, the aforementioned function `showMessage(from, text)` can be calle
|
|||
showMessage("Ann");
|
||||
```
|
||||
|
||||
That's not an error. Such call would output `"Ann: undefined"`. There's no `text`, so it's assumed that `text === undefined`.
|
||||
That's not an error. Such a call would output `"Ann: undefined"`. There's no `text`, so it's assumed that `text === undefined`.
|
||||
|
||||
If we want to use a "default" `text` in this case, then we can specify it after `=`:
|
||||
|
||||
|
@ -255,7 +255,7 @@ alert( result ); // 3
|
|||
|
||||
The directive `return` can be in any place of the function. When the execution reaches it, the function stops, and the value is returned to the calling code (assigned to `result` above).
|
||||
|
||||
There may be many occurences of `return` in a single function. For instance:
|
||||
There may be many occurrences of `return` in a single function. For instance:
|
||||
|
||||
```js run
|
||||
function checkAge(age) {
|
||||
|
@ -340,7 +340,7 @@ Functions are actions. So their name is usually a verb. It should briefly, but a
|
|||
|
||||
It is a widespread practice to start a function with a verbal prefix which vaguely describes the action. There must be an agreement within the team on the meaning of the prefixes.
|
||||
|
||||
For instance, functions that start with `"show"` -- usually show something.
|
||||
For instance, functions that start with `"show"` usually show something.
|
||||
|
||||
Function starting with...
|
||||
|
||||
|
@ -359,20 +359,20 @@ createForm(..) // creates a form (and usually returns it)
|
|||
checkPermission(..) // checks a permission, returns true/false
|
||||
```
|
||||
|
||||
With prefixes at place, a glance at a function name gives an understanding what kind of work it does and what kind of value it returns.
|
||||
With prefixes in place, a glance at a function name gives an understanding what kind of work it does and what kind of value it returns.
|
||||
|
||||
```smart header="One function -- one action"
|
||||
A function should do exactly what is suggested by its name, no more.
|
||||
|
||||
Two independant actions usually deserve two functions, even if they are usually called together (in that case we can make a 3rd function that calls those two).
|
||||
Two independent actions usually deserve two functions, even if they are usually called together (in that case we can make a 3rd function that calls those two).
|
||||
|
||||
Few examples of breaking this rule:
|
||||
A few examples of breaking this rule:
|
||||
|
||||
- `getAge` -- would be bad if it shows an `alert` with the age (should only get).
|
||||
- `createForm` -- would be bad if it modifies the document, adding a form to it (should only create it and return).
|
||||
- `checkPermission` -- would be bad if displays the `access granted/denied` message (should only perform the check and return the result).
|
||||
|
||||
These examples assume common meanings of prefixes. What they mean for you is determined by you and your team. Maybe it's pretty normal for your code to behave differently. But you should have a firm understanding of what a prefix means, what a prefixed function can and what it cannot do. All same-prefixed functions should obey the rules. And the team should share the knowledge.
|
||||
These examples assume common meanings of prefixes. What they mean for you is determined by you and your team. Maybe it's pretty normal for your code to behave differently. But you should have a firm understanding of what a prefix means, what a prefixed function can and cannot do. All same-prefixed functions should obey the rules. And the team should share the knowledge.
|
||||
```
|
||||
|
||||
```smart header="Ultrashort function names"
|
||||
|
@ -385,7 +385,7 @@ These are exceptions. Generally functions names should be concise, but descripti
|
|||
|
||||
## Functions == Comments
|
||||
|
||||
Functions should be short and do exactly one thing. If that thing is big, maybe it's worth to split the function into few smaller functions. Sometimes following this rule may not be that easy, but it's a definitely good thing.
|
||||
Functions should be short and do exactly one thing. If that thing is big, maybe it's worth it to split the function into a few smaller functions. Sometimes following this rule may not be that easy, but it's definitely a good thing.
|
||||
|
||||
A separate function is not only easier to test and debug -- its very existence is a great comment!
|
||||
|
||||
|
@ -440,7 +440,7 @@ function name(parameters, delimited, by, comma) {
|
|||
}
|
||||
```
|
||||
|
||||
- Values passed to function as parameters are copied to its local variables.
|
||||
- Values passed to a function as parameters are copied to its local variables.
|
||||
- A function may access outer variables. But it works only from inside out. The code outside of the function doesn't see its local variables.
|
||||
- A function can return a value. If it doesn't then its result is `undefined`.
|
||||
|
||||
|
@ -454,4 +454,4 @@ Function naming:
|
|||
- A function is an action, so function names are usually verbal.
|
||||
- There exist many well-known function prefixes like `create…`, `show…`, `get…`, `check…` and so on. Use them to hint what a function does.
|
||||
|
||||
Functions are the main building blocks of scripts. Now we covered the basics, so we actually can start creating and using them. But that's only the beginning of the path. We are going to return to them many times, going more deeply in their advanced features.
|
||||
Functions are the main building blocks of scripts. Now we've covered the basics, so we actually can start creating and using them. But that's only the beginning of the path. We are going to return to them many times, going more deeply into their advanced features.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue