Subroutine Design Principles

A subroutine (routines) is a method, function, or procedure that can be called to implement a specific function ). For example, Java methods and functions in C ++. Modern programming languages such as Java, C ++, VB, JavaScript, and Ruby support both functions and processes. Generally, a function refers to a subroutine with a return value, and a process refers to a subroutine without a return value. In C ++, all subprograms are converted into functions. In fact, those functions whose return values are void are also in semantics. The difference between a function and a process is more semantic than syntax. Language purification advocates 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 results through parameter operations. Using the JS example function sum1 (x, y) {return x + y} function sum2 (x, y) {alert (x + y)} sum1 is a function, it has input and return results; sum2 is a process that accepts input and processes the input (prints the output results), but does not return results. A good subroutine must follow the following principles: parameters with a proper name length for High Cohesion 1. High Cohesion is an important concept in computer science, it was proposed by Larry Konstantin in a paper in 1974. It is divided into the following 1. functional cohesion (the highest) is the best and strongest cohesion, that is, a sub-program only executes one operation, and some books also call it "only one thing and one thing is done ". Most of the operations performed by this subroutine are consistent with their names, such as sum execution addition and deletePage Deletion page. 2. Sequential cohesion indicates that the subprogram needs to perform operations in a specific order. These steps need to share data and complete the functions of the subprogram only after they are fully executed. For example, you need to calculate A first, then use A to calculate B, and then take B to calculate C. 3. Communicational cohesion means that different subprograms use the same data but there is no connection. 4. Temporary cohesion (Temporal cohesion) refers to subprograms that contain operations that need to be executed at the same time. 5. Logical cohesion refers to the fact that several operations are put into the same program and an operation is selected to be executed using the input control mark. 6. Even hot cohesion (the lowest Coincidental cohesion) refers to the inline that is not directly visible in each operation in the subprogram, also known as "no cohesion" or "chaotic cohesion ". 2. A well-named name can clearly describe what the subroutine has done. The following are some naming considerations 1. describes the functions completed by subprograms. 2. avoid meaningless, simulated, or ambiguous words. do not distinguish subprograms by numbers alone. determine the length of the subroutine name as needed. the return value must be described. 6. usually Verb + noun form 7. use opponent words, such as add/remove, begin/end, first/last, get/put, up/down/, show/hide, and open/close. 3. Moderate length "the first element of a subroutine/function is short, and the second rule is still short," said Uncle Bob. Theoretically, the maximum length of a subroutine is usually a screen of code, about 50-rows. A Study of subroutines found that the probability of modifying a subroutine with an average of 1989-lines of code is the lowest (Lind and Vairavan ). One IBM study found that subroutines with more than 500 lines of code were the most prone to errors. After more than 500 rows, the error rate of the subroutine is proportional to the number of lines of code. In object-oriented programming, a majority of subprograms are accessors (getter), which are very short. At any time, a complex algorithm will always lead to a longer subroutine, which allows the length to be increased to 100 to 200 rows. 4. The interface between reasonable parameter subprograms is the most error-prone place in the program. A study conducted by Basili and Perrricone found that 39% of errors in the program are internal interface errors. That is, an error occurs when subprograms communicate with each other. The following principles should be followed: 1. Sort parameters in the input-Modify-output order. Do not randomly arrange parameters in alphabetical order, but first list the input parameters, that is, the input and output parameters, and finally the output parameters. For example, Ada requires special keywords in and out. Procedure InvertMatrix {originalMatrix: in Matrix; resultMatrix: out Matrix;} 2. If several subprograms use similar parameters, they should be arranged in the same order. Dom = {setWidth: function (elem, value ){//...}, setHeight: function (elem, value ){//...}} 3. all parameters are used. If this parameter is defined, it should be used. If it is not used, it should be deleted. 4. Put the status or error variables behind them. The status and variables used to indicate an error should be placed at the end of the parameter table. They are only ancillary functions of the program and are only used for output parameters. 5. do not use the subroutine parameters in the JS Code of the working Variable function process (inputVal) {inputVal = inputVal-10; return inputVal}. A variable declaration is omitted. inputVal is easy to misunderstand, that is, the input and output parameters are changed to function process (inputVal) {var outputVal = inputVal-10; return outputVal} 6. the number of subprograms is limited to seven. Uncle Bob said, "the ideal number of parameters is zero, followed by single-parameter functions, and double-parameter functions. We should avoid three-parameter functions as much as possible ". Psychology research found that it is difficult for humans to remember information in more than seven units. This issue has been applied in various fields.