The design principle of JS function

It is generally considered that a function is a subroutine with a return value, and a procedure is a subroutine that has no return value. In C + +, all subroutines become functions, in fact those whose return value is void
The function is also semantically a process. The difference between a function and a process is more of a semantic difference than a grammatical one.

Language purists believe that a function should have only one return value, which is the same as a mathematical function. That is, the function only accepts input (parameters) and returns the result by a parameter operation
。 In addition, the effect is called a function side effect, such as modifying global variables.

function sum1 (x, y) {
Return X+y
}
function sum2 (x, y) {
Alert (x+y)
}
Sum1 is a function that has input and returns a result; Sum2 is a process that accepts input, processes input (prints output), but does not return results.

A good subroutine should follow these guidelines

High cohesion
A good name
Medium length
Reasonable parameters

First, cohesion poly-sex

Cohesion is a very important concept in computer science, presented by Larry Konstantin in a 1974 paper. It is divided into the following

1. Function cohesion (functional cohesion, highest)

Best one of the strongest cohesion, that is, a subroutine performs only one operation, and some books also say "Do one thing, do a good thing". The action that the SEED program performs
is consistent with its name majority, such as Sum, deletepage delete the page.

2. On-order cohesion (sequential cohesion)

Refers to the sub-program domestic demand in a specific order to perform operations, these steps need to share data, and after the full implementation of the sub-program complete function. For example, a must be calculated first,
Then use a to calculate B, then take B to calculate C.

3. Communication on the cohesion (communicational cohesion)

means that the subroutine uses the same data for different operations, but there is no contact.

4. Temporary cohesion (temporal cohesion)

Refers to subroutines that contain operations that are put together because they need to be executed at the same time.

5. Logical cohesion (Logical cohesion)

A number of operations are placed in the same program, and one of them is selected by the incoming control flag.

6. Even heat cohesion (coincidental cohesion minimum)

Refers to an inline, also known as "no cohesion" or "chaotic cohesion", that is not directly visible in each operation of the subroutine.

Second, a good name

A good name can clearly describe everything that a subroutine does. Here are some naming considerations

1. Describe the functions performed by the subroutine

2. Avoid the use of meaningless, simulated or ambiguous words

3. Do not distinguish between different subroutine names by numbers only

4. Determine the length of the subroutine name as needed

5. Describe the return value

6. Usually verb + noun form

7. Use antithesis words such as add/remove, Begin/end, First/last, Get/put, up/down/, Show/hide, Open/close.

Three, the length is moderate

"The first element of a subroutine/function is short, the second rule is short," says Uncle Bob. In theory, the maximum length of a subroutine is usually a
Screen code, about 50-150 lines.

A sub-program study found that subroutines with an average of 100-150 lines of code had the lowest chance of modification (Lind and Vairavan 1989).

One IBM study found that the most error-prone are subroutines that exceed 500 lines of code. After more than 500 lines, the error rate of the subroutine is proportional to the number of lines of code. In the face of
In object programming, a large number of subroutines are accessor subroutines (getter), both of which are very short. Complex algorithms always lead to longer subroutines at any time.
In this case, the length is increased to 100 to 200 lines.

Four, reasonable parameters

The interface between subroutines is the most error-prone place in the program, and a study by Basili and Perrricone found that 39% of the errors in the program are internal interface faults
Miss. This is the error that occurs when the subroutine communicates with each other. should be handled in accordance with the following principles

1. Arrange the parameters in the order of input-modify-output. Do not randomly arrange the parameters in alphabetical order, but should first list the input parameters, then as input and as
The output parameters, and finally the output parameters. Ada, for example, requires a special keyword in,out.

Procedure Invertmatrix {
Originalmatrix:in Matrix;
Resultmatrix:out Matrix;
}

2. If several subroutines use similar parameters, the order of the parameters should be aligned.

Dom = {
Setwidth:function (Elem, value) {
// ...
},

Setheight:function (Elem, value) {
// ...
}
}

3. Use all parameters, now that you have defined the parameter, you should use it, and if not, you should delete it.

4. Place the state or the wrong variable in the back, state, and the variables that indicate the error should be placed at the end of the parameter table. They are only a subsidiary function of the program and are only used
to the output parameters.

5. Do not use the parameters of the program for working variables

function process (inputval) {
Inputval = inputVal-10;
Return Inputval
}
This JS code, omitted a variable declaration, Inputval is very easy to misunderstand, that is, the input is output, change to the following

function process (inputval) {
var outputval = inputVal-10;
Return Outputval
}
　　

6. The number of parameters of the subroutine is limited to less than 7. Uncle Bob said more extreme. "The ideal number of parameters is zero, followed by a single-parameter function, again a double-parameter letter
The three-parameter function should be avoided as far as possible. Psychological studies have found that it is difficult for humans to remember more than 7 units of information. This discovery has been applied in various fields.