Linuxaid.com.cn 01-06-11 11:38 348P
Axing
The first quarter of the netizen HEM has been reproduced, see:
http://www.9cbs.net/develop/library/misc/misc/8168.shtm
In the previous section, we discussed the impact of beautiful subroutines on the overall system, but everyone may still be more vague, let us look at an actual example: Before discussing the details of high quality subroutines, we first consider two basic noun. What is "subroutine"? The subroutine is a modified function or process with a single function. For example, functions in C, function or process in Pascal or ADA, subroutines in Basic or subroutines in Fortran. Sometimes the macro in C or the code block called by Gosub in the BASIC can also be considered a subroutine. The techniques used to create a high quality subroutine can be used in generating the above functions or processes. What is "high quality subroutine"? This is a problem that is more difficult to answer. In turn, the simplest answer means that the high quality subroutine is nothing. The following is a typical inferior subroutine (written in Pascal): Procedure HandleStuff (Var InputRec: CORP_DATA, CrntQtr: integer, EmpRec: Emp_DATA, Var EstimRevenue: Real, YTDRevenue: Real, ScreenX: integer, ScreenY: integer, Var NewColor: Color_TYPE, Var PrevColor: COLOR_TYPE, Var Status: sTATUS_TYPE, ExpenseType: integer); begin for i: = 1 to 100 do begin InputRec.revenue [1]: = 0; InputRec.expense [i]: = CorpExpensse [CrntQtr, i ] end; UpdateCorpDatabase (EmpRec); EstimRevenue: = YTDRevenue * 4.0 / real (CrntQtr) NewColor: = PrevColor; status: = Success; if ExpenseType = 1 then begin for i: = 1 to 12 do Profit [i]: = Revenue [I] -Expense.Type [I] end else ife = 2 Then Begin peoft [i]: = revenue [i] - else.type2 [i] end else if expensetype = 3 THEN Begin Profit [I]: = Revenue [i] - Expense.Type3 [i] End end What is the problem with this subroutine? Give you a prompt: you should find 10 questions at least. When you list the problems found, look at the problems listed below; • The name of the program is confused. HandleStuff () can tell us what the program is doing? · The program is not explained. · The layout of the subroutine is not good. The physical organization of the code has almost no information in the form of its logical organization.
The use of the layout is too quiet, and the layout of each part of the program is different. about this point. As long as you compare the style of exportype = 2 and ExpenSetype = 3, it is clear. · The input variable value INPUTREC of the subroutine has been changed. If it is an input variable, it doesn't change it. If you want to change its value, it should not be called input variable inputRec. The subroutine has been read and written for global variables. It reads the variable from Corpexpense and writes to Profit. It should communicate with the access subroutine without reading and writing global variables directly. · The function of this subroutine is not single. It initializes certain variables. Write an operation for a database and conduct certain calculations, and they can't see any contact. The function of a subroutine should be single, clear. • Measures to prevent illegal data in the subroutine. If the value of CrntQTR is "0", the expression YTDREVENUE * 4.0 / REAL (CrNTQTR) will occur errors that are zero. · Several constants were used in procedures: 100, 4.0, 12, 2 and 3. • Only two domains of the domain's corp_data type parameters in the program are used. If only two domains are used, it will only be passed to a specific domain rather than the entire structured variable. · Some parameters in the subroutine are not used. Screenx and Screeny did not involve in the program. · One parameter in the program is calibrated. Prevcolor is calibrated as a variable type parameter, but it is not assigned to it in the program. · There are too many parameters in the program. The reasonable upper limit of the number of parameters in the program should be about seven. And this program is up to 11. The parameters in the program are too afraid, I am afraid that no one will check them carefully, and even the number is not willing. Such a small code has so many mistakes, these mistakes You can avoid it? If so, congratulate you, your programmer's skill is quite deep. Although these mistakes are not very dense, it does not affect the correctness and speed of the program. In the system increasingly complex, if the complexity, readability, and coupling of each subroutine in the system affects the success of the overall system. But if you write a personal program, you are the abuse of yourself, if you are a molecule for the development group, then your approach is the abuse of companions. In addition to the computer itself, the subroutine can be said to be the most important inventions of computer science. Subprogram makes very good reading and it is also very easy to understand that any characteristics in programming languages cannot be compared to this. Like the subroutine like in the above example, it is simply the trample of subroutines, and it can even be a crime. Subprints are also the best way to save space and improve performance. Imagine, if you use the code segment instead of each call to the subroutine in the program, how large the program will be. If you don't store multiple reused code segments in a subroutine, but directly put it in the program, it will be a difficult thing to perform performance improvement. It is a subroutine that makes modern programming possible. Now you may have some impatient. "Yes, the subroutine is indeed very good, I have been using it." You said, "Your discussion seems to be correct, what do you want me to do?" I want to say: There are many reasonable reasons to make us generate a subroutine. But there is a good way to generate a method. As a computer professional undergraduate, the main reason for generating subroutines can be considered to avoid repetition of code segments. I use the entry textbook told me that the reason why it is used because it avoids the repetition of the code segment, making the development, debugging, annotation, and maintenance work of a program make it very easy. In addition to some grammatical details about how to use parameters and local variables, this is all of the textbooks on the theory of subroutine and practices. This is not a complete and reasonable explanation.
The benefits of subroutines We have explained in detail in the previous section. Since there are so many benefits of the subroutines, what is the difficulty of writing a beautiful and even perfect subroutine, in fact, this is a thought and habit. The programmer must be the kind of person wearing a jarner, listening to the rock written program? I think the real programmer should be meticulous, analyzed, determine the architecture, do a profile design and detailed design, unit test, and organize all documents. Trouble, it is very trouble, but this will bring you unexpected surprises. You will find that your program is so clear: more versions will not give your head to your head, a small mistake is easy to be positioned in tens of thousands of lines, and users present new demand is your face. No more ugly .... All these simply mean that you successfully control the procedure from your hand. The biggest psychological barrier to write subroutines is to write a simple subroutine for a simple purpose. Write a subroutine with only two or three lines of code seems to be completely unnecessary. But experience shows that small subroutines are also very helpful. The small subroutine has many advantages, one of which is improved readability. I have used such a code segment in the program, which has been more than a dozen times in the program: Points = DeviceUnits * (Points_Per_Inch / deviceUnitsperinch ()) This is not the most complex line you have read. Code. Many people understand that it is used to convert. They will also understand that every line in the program is doing the same thing, but it can also become more clear, so I created a properly named subroutine to do this. DeviceUnitStopoints (DeviceUnits Integer): Integer; Begin DeviceUnitStopoints = DeviceUnits * (Points_Per_inch / DeviceUnitsperinch ()) End This piece of code is basically the following after using this segment. : Points = DeviceUnitStopoints (DeviceUnits) This obviously more readable and even has reached the point of self-explanation. This example also implies another reason for the simple operation to put into function: simple operation tends to become complex operation. When I write this subroutine, I don't know this, but in some case, when a device is turned on, DeviceUnitPerinch () will return zero, which means that I have to take into account the "0" except, Thus, they require an additional three lines of code; DeviceUnitsToPoints (DeviceUnit: integer): integer; begin if (DeviceUnitsPerInch () <> 0) then DeviceUnitsPoints = DeviceUnits * (POINTS_PER_INCH / DeviceUnitsPerInch ()) else DeviceUnitsToPoints = 0 end if the original code The line is still more than ten times in the program, then this test has to be repeated more than a dozen times and needs to add 36 lines of code. And a simple subroutine is light and easy to turn 36 to 3. In this section, we see the quality of the subroutine, the difference in the impact of the high-quality subroutine and low quality subroutine is extremely obvious.
