Linuxaid.com.cn 01-06-11 12:06 342P
Axing
What should I pay attention to writing a beautiful subroutine? Prior to continuing the following discussion, we must confirm that the methods mentioned below and the examples just react with a programming idea. No matter what you use, you can integrate your own language into the method. , Experience the taste, so that you will feel that there is a great harvest, let us enter the real stage, what is a good subroutine? The subroutine name is appropriate for a proper subsystem that should clearly describe everything made by the program. The following is a guidelines for the subroutine 'effective naming: For the name of the process, you can use a strong verb with a target. A function of a function is often operated for a certain goal. The name should reflect what this process is to do, and the operation of a target means that we should use the Binbin phrase. For example, printReport (), checkotderlnfo (), etc., is about the more appropriate names of the process. In the object-oriented language, it is not necessary to add an object name because the object itself has appeared when it is called. At this time, you can help with names such as Report.Print (), ORDERLNFO.CHECK () and MonthlyReventu.cafe (). As Report. PrintReport This type of name is redundant. For function names, a description of the return value can be used. A function returns to a value, the function should be named by the value it returns, such as COS (), printerReady (), currentpencolor (), and so on, because it accurately describes what the function will return. Avoid meaningless or ambiguous verbs. Some verbs are very flexible, there can be any meaning, such as handlecalculation (), processInput () is equal to the program noun and not tells you what it is. These names tell you most of them, they are working with some processing related to calculation or input. Of course, there is an exception to the use of "Handle" in a specific technical situation. Sometimes the only problem with the subroutine is that its name is too blurred, and the design of the subroutine itself may be very good. If you use formataandprintoutput () instead of Handleoutput (), this is a very good name. In some cases, the meaning of the verbs used is that the work is too blurred because the subroutine itself is. The subroutine has a functionally unclear defect, and its name is blurry is just a marker. If this is the case, the best solution is to re-construct this subroutine, clarify their functions, so that they have a clear and accurately describing their functionality. Describe everything done by the subroutine. In the subroutine name, all output results and its additional results should be described. If a subroutine is used to calculate the total number of reports and set a global variable to indicate that all data is ready, wait for printing, then ComputeReportTotal () is not a full name. ComputeReportTotaRandSetPrintingReadyvar () is another too too stupid name. If the subroutine comes with additional results, it will inevitably produce a lot of long and stinky names. The solution should not be used in the use of insufficient names, but to program the principles that directly implement each thing, avoiding the program with additional results. The length of the name is subject to need. Studies have shown that the optimum length of the variable name is 9 to 15 letters, and subroutines are often complicated than variables, so their name is also longer. MichaelRees in the University of Southampton believes that the appropriate length is 20 to 35 letters.
However, in general, 15 to 20 letters may be more realistic, but some name may sometimes be longer than it. Establish a convention for common operations. In some systems, it is very important to distinguish a variety of different operations. Naming conventions may be the simplest and most reliable way to distinguish these operations. For example, when developing a 0s / 2 display manager, if the subroutine is about direct input, add a "get" prefix in front of its name, if it is not directly entered, add "Query" prefix, which returns the current input The character's getLnputChar () will clear the input buffer. It is also querylnputchar () that returns the current input character, does not clear the buffer. For naming rules, many books have done a detailed elaboration and description. Among them, there are very famous Hungarian nomenclas, based on this, and various languages have been derived from a variety of different naming rules, but in terms of thinking, if people can make people mean the meaning of the name, the function is eight Nine is not left ten, it is successful. The above mentioned although the rule that you usually contact is not exactly the same, it represents a naming thought and is very versatile. Strong cohesive cohesiveness refers to the tightness of contact between various operations in a subroutine. Some programmers like to use the word "intensity" instead of cohesiveness, how is the relationship between various operations in a subroutine? A function of a function such as SiN () is very strong, because the work engaged in the entire subroutine is around a function. The degree of coefficient like Sinandtan () is much lower, because the subroutine is made is an item. Emphasize the purpose of strong correlation is that each subroutine requires only one job without having to consider other tasks too much. The advantage of this is to improve reliability. Through the survey of 450 Fortran subroutines, 50% of the strong inner polymer subprofits are not wrong, and only 18% of weak internal polygered subprograms are unlike (Card, CARCH, and AgResti 1986). Another survey of another 450 subprograms indicates that an error chance of a weak inner polymer subroutine is 6 times higher than that of the strong internal polymerization, while the correction cost is 19 times (Selby and Basili 1991). The discussion of the cohesive cohesiveness is generally referred to as a few levels. The concept of understanding is much more important than the noun. These concepts can be utilized to generate cohesive subroutines as possible. The idea of cohesiveness is made by Wayne Stevens, Glenford MYERS, and Larry Constantine et al. In a paper published in 1974, since then, some parts of this idea have gradually improved. Here are some of the internal gathering types that are usually considered to be acceptable: functional cohesiveness. Functional cohesiveness is the strongest and best, when the program executes an item and is just a job, this is the cohesiveness, such coexity: sin (), getcustomername (), EraseFile (), CaldoAnPayment () and geticonlocation (), and more. Of course, this evaluation is only true when the name of the subroutine is consistent with its actual content. If they still do other work, their cohesiveness is much lower and naming is not appropriate. Sequential cohesiveness. Sequential cohesiveness refers to an operation that includes, step-by-step sharing data, and does not form a complete function in a sub-program, assumes that a subroutine includes five operations: open files, read files, and perform two calculations. , Output results, turn off files. If these operations are done by two subroutines, dostep1 () opens files, read files, and calculation operations, while dostep2 () makes output results and turn the file operation. Both subroutines have sequential cohesiveness.
Since the operation is separated by this manner, there is no independent function. However, if you open a file and read file with a subroutine called getFileData (), then this subroutine will have functional cohesiveness. When the operation is completed, they can form a subroutine with functional cohesiveness. In fact, if you can name a subroutine with a typical mobile phrase, it is often functional cohesiveness, not the order of cohesiveness. It is very difficult to name a substructure of a sequential cohesiveness, so it produces two-visual names like dostep1 (). This often means that you need to reorganize and design a subroutine to make it functional cohesive. Communication cohesiveness. The communication cohesiveness is in a subroutine, and the two operations are only used in the same data without any other contacts. For example, in getnameandchangephonenumber () subroutine, if Name and Phonenumber are placed in the same user record, then this subroutine is the communication cohesiveness. This subroutine is engaged in two instead of work, so it does not have functional cohesiveness. Both Name and PhonEnamber are stored in user records, and they do not have to read them in a particular order, so it does not have sequential cohesiveness. The cohesiveness in this sense is still acceptable. In practice, a system may need to change the phone number while reading a name. A system containing such subroutines may be somewhat awkward, but it is still very clear and maintenance is not bad. Of course, from aesthetic perspective, it has a certain gap with a subroutine that only works only. Temporary cohesiveness. Because the reason is performed simultaneously, it is placed in the same subroutine, and temporary cohesivity is generated. Typical examples are: Startup (), CompleteneWemPloyee (), Shutdown (), etc., some programmers believe that temporary cohesiveness is unacceptable because they sometimes contact everything with poor programming, such as startup () This type of subroutine often contains a chow-like code in Dongzhi. To avoid this problem, you can design the temporary cohesive subroutine into a series of work. The aforementioned STARTUP () subroutine can include: reading a profile, initializing a temporary file, establishing a memory management, and the initialization screen. To make it most effectively complete these tasks, you can make this subroutine to call other subroutines, not directly to these tasks themselves. A subroutine is only simply simple to complete a basic function, but you may ignore the focus of subroutine cohesiveness because of such or such reasons. In fact, you only need to spend some time in front of the official writing process, write good head files and makefile files. If you want to know where your public function is placed, how your business rules allocate refining, when writing the program, spend some time a little bit to sort out your code. All these times will bring you unexpected benefits. Think about how you manage your huge collection. Insensicular cohesive cohesive cohesiveness, it is generally not available. The consequences often produce some tissue chaos and difficult to debug and improve the code. If a subroutine has poor cohesive, it is best to recreate a better subroutine without trying to fix it. I know what should be avoided is very important. Here is some non-desirable cohesiveness: process cohesiveness. The operation in the subroutine is in a particular order, that is, process cohesiveness. Unlike sequential cohesiveness, the order of operation in process cohesive is not the same data. For example, if the user wants to print a report in a certain order, the subroutine owned is used to print sales revenue, expenses, and employee phones. Then naming this subroutine is very difficult, and the ambiguous name is often representing some kind of warning. Logical cohesiveness.
