First article: Beautiful procedures require a beautiful subroutine
Linuxaid.com.cn
Axing
〖
Back to〗 Forward〗
I have seen the programmakers who wrote more than 1,000 lines of MAIN functions, and it is not a few. Don't you know how to use a function? Not necessarily, but it is certain that they have not known as a beautiful code. So why do we need a subroutine? Let's take a look at how Steve McConnell said. The following is about why some reasonable causes of the program, some of which may have a place overlapping each other. Reduce complexity. The most important reason for using subroutines is to reduce the complexity of the program, and you can use subroutines to implies information so that you don't have to consider this information. Of course, when you write a subroutine, you also need to consider this. However, once you write a binder, you may not have to consider its internal work details, as long as it is called. Another reason for creating a subroutine is to minimize the space of the code segment, improve maintainability and correctness. This is also a nice explanation, but if there is no abstract function of the subroutine, it will not be wise to manage complex programs. One of the reasons that need to be detached from another subroutine is that the internal cycle and condition of excessive numbers are judged. At this time, this partial loop and determination can be detached from the subroutine to make it a separate subroutine to reduce the complexity of the original subroutine. Avoid the code segment repetition. Unquestionable, the most common cause of the generated subroutine is to avoid the code segment repetition. In fact, if the code in two different subroutines is similar, this often means that the decomposition work is incorrect. At this time, you should take the duplicate code in the two subroutines, put the public code in a new universal subroutine, and then let the two subroutines call new universal subroutines. You can save a lot of space by making public code only once. It is also very convenient to change at this time, as you can change the code in one place. At this time, the code is also more reliable because just check the code in one place. Moreover, this also makes the change more reliable, because it is not necessary to constantly, very similarly changed, and this change is often considered to write the same code this error assumption. Limit the impact of the change. Since the independent area is changed, the impact thereof is limited to one or most regions. It is necessary to design the most likely changed area to be the easiest to change. The most likely to be changed includes: hardware dependence, input and output portions, complex data structures, and business rules. Injid the order. It is a good idea to impose a non-specific order of processing events. For example, if the program typically reads data from the user, then read secondary data from a file, whether it is a subroutine that reads user data or reading a subroutine in a file, it should not be Another subroutine is relied on whether the data is read. If you use two lines of code to read the data on the top of the stack, and reduce a stacktop variable, you should put them in a popstack () subroutine, when designing the system, which one can be executed first, then write a subroutine Which one is impossible to implement. Improved performance. By using subroutines, you can optimize code segments in a place rather than simultaneous places. Put the same code segment in a subroutine, you can benefit all the subroutines that call this subroutine by optimizing this subroutine. Putting code segments into subroutines also make it easy to use faster algorithms or perform faster languages (such as compilation) to improve this code. Centralized control. Control all tasks in a place is a good idea. Control may have many forms. Knowing the number of entrances in a table is one of the forms, controlling the hardware system, such as control of the disk, tape, printer, and plotting machine, is one of the other forms. The subscriber is read from a file, and the file is written to the file using another subroutine is a form of centralized control.
This is very useful when you need to convert this file into a data structure that resides in memory, because this change only changes the access subroutine. The specialized subroutine reads and changing the internal data content, and is also a concentrated control form. The ideological and information implicitness of centralized control is similar, but it has unique inspiration capabilities, so it is worth putting it in your toolbox. Include the data structure. The details of the data structure can be implicit, so that most of the programs do not have to worry about this messy computer science structure, and can process data from how data in the problem domain is used. A subroutine implied to implement detail provides a considerable abstract value, thereby reducing the complexity of the program. These subroutines have set the data structure in one place, which reduces the possibility of errors when processing the data structure. At the same time, they also change the data structure without changing the vast majority of programs. Include global variables. If you need to use global variables, you can use it to use it to use global variables as the geographic variables like the subroutine: You don't have to change the program to change the data structure; monitor the data of data; use access subroutines Constraints can also encourage you to consider this data is not global; it is likely to handle it into part of a few subrouties in a module or to process a part of an abstract data. Include pointer control. The pointer is readily readable and it is easy to cause errors. By independent of them in a subroutine, you can focus on the operational intent rather than the mechanical pointer operation itself. Moreover, if the operation is only performed at one place, it is easier to ensure that the code is correct. If you find a better data structure than your pointer, you can change the program without affecting the subroutine that should be used. Reuse the code segment. Putting the code segment reuse in the modular subroutine, it is much easier than the code segment in a large number program. Plan to develop an appraisore. If you want to improve a program, it is best to put the part that will be changed in the subroutine and independent. In this way, this subroutine can be changed without affecting the rest of the program, or simply replacing it with a new subroutine. A few years ago, I have been responsible for the group of the salesman to prepare a series of software, and we have to complete a specific procedure according to the insurance rate, quotation format, etc. of each salesman. Most of these programs are all the same: enter the subroutine of potential customers, information stored in the customer database, view, calculate price, etc. This team modularize the program so that the part of the salesman is placed in its module. The initial program may be developed for three months, but after this, we only rewrite several modules that can be numbered. Two or three days may write a requesting process, which is a kind of enjoyment! Improve the readability of partial code. Put a piece of code in a well-named subroutine, which means the best way to make its function. This doesn't have to read such a statement: if (node <> null) while (node.next <> null) do node = node.next leafname = "" instead of it: Leafname = Getleafname (Node This program is so short, and what it needs is just an appropriate name. Use a function call instead of a six-line code segment so that subroutine complexity containing this code is greatly reduced, and its function is also automatically commented. Improve portability.
