Checklist and summary-code encyclopedia

The design has been iterative for many times and ultimately determines the best one. Whether to use both the Top-down and bottom-up approaches to solve the design problem. Whether the interaction between a class and a class has been designed to be minimized. Is the design divided into layers? Are you satisfied with the way you decompose this program into subroutines, packages, and classes? Programs are not easy to maintain. Whether the design is streamlined. Is it absolutely necessary to design every part of it? On the whole, does your design help minimize the complexity of contingency and nature?

Class design Do you think of classes in a program as abstract data types. Whether to evaluate their interfaces from this perspective. Class has a central purpose. The name of the class is appropriate. Whether its name expresses a new purpose. Whether the interface of the class exhibits a consistent abstraction. The interface of a class makes it clear to know how to use it. The interface of a class is abstract so that you do not have to worry about how he implements his service. Can you think of the class as a black box? class provides a sufficiently complete service that other classes do not need to use their internal data. Whether extraneous information has been removed from the class. Have you considered further decomposing the class? Whether the integrity of its interfaces is maintained when the class is modified. Whether to minimize the accessibility of members. Whether to avoid exposing the data members of the class. Class avoids assumptions about how its consumers, including their derived classes, will use it. Class is not dependent on other classes. Is it loosely coupled? Inheritance is used only to establish an is a relationship. Whether the derived class follows the LSP principle. Whether the inheritance level is shallow. Whether there are only about seven or fewer members in the class. To minimize the number of subroutines that call classes directly or indirectly to other classes. Whether a class is written with other classes when it is absolutely necessary. Whether all the data members are initialized in the constructor.

Is there a good reason for subroutines to create subroutines? All parts of a subroutine that are suitable to be presented separately are not already presented in a separate subroutine. Whether the name of the procedure uses a strong, clear verb garbin phrase, and whether the function's name describes its return value. Whether the subroutine's name describes all the things it does. Whether the subroutine has a strong functional cohesion. Whether there is a looser coupling between subroutines. Whether the connection between the subroutine and other subroutines is minimal, clear, visible, and flexible. Whether the length of the subroutine is determined by its function and logical nature, rather than by any artificial coding standard. Whether the subroutine's parameter table shows a holistic and consistent abstraction. Whether the subroutine parameters are arranged in a reasonable order. is consistent with the parameters of a similar subroutine. Interface is assumed to be described in the document. The subroutine has no more than 7 parameters. Whether every input parameter is used, and whether every output parameter is used. Whether the subroutine avoids using the input parameter as a work variable. If the subroutine is a function, then it can return a valid value in all possible cases.

Whether a defensive programming subroutine protects itself from harmful input data. Do you use assertions to illustrate programming assumptions? Which includes the former condition and the post condition. Whether the assertion only describes what never should have happened. Do you specify a specific set of error handling techniques in your architecture or high-level design? Do you specify whether or not to make error handling more robust or correct in architecture or high level design? Is there code in the Code for secondary debugging? The amount of code that is introduced in defensive programming is neither too much nor too small. Have you defined a standardized exception handling scheme in your project? If possible, handle the error locally instead of running it as an exception. All exceptions are on the same abstraction level as the subroutine that throws them. Each exception contains all the background information about the occurrence of the exception. There are no empty catch statements in the code. The code that checks for harmful input data also checks for intentional buffer overflows, SQL injection, HTML injection, integer overflow, and other malicious input data. Whether all error return codes have been checked. Whether all of the exceptions were caught. In the error message, avoid the information needed to help attackers hack into the system.

If the pseudocode has been checked, all prerequisites have been met. Define the problem that this class is going to solve. High-level design is clear. Can you give this class and each subroutine a good name? Have you considered how to test this class and each of its subroutines? On the question of efficiency, do you consider it mainly from the perspective of stable interface and readable implementation. Or is it primarily from the point of view of meeting the expected goals of resources and speed? Look for available subroutines or components from standard library functions and other code libraries. Have you checked the useful algorithms from the reference books? Do you want to design each child program with detailed pseudocode? Have you checked the pseudocode in your mind? Are these pseudocode easy to understand? Have you focused on the warning messages that might have put you back in the design? Whether to translate the pseudocode correctly into the code. Have you repeatedly used the Pseudocode programming process? There is no explanation for these assumptions when they are made. Have you removed the redundant annotations? Did you take the best of the iterations a few times? Or did it stop after the first iteration. Do you fully understand your code? Whether the code is easy to understand.

The variable declaration position is near the position where the variable was first used. Initialize the variable as much as possible at the same time as the variable declaration. Have the counters and accumulators been properly initialized? If you need to use it again, before you reinitialize it. Properly reinitialize "variables in code that needs to be executed repeatedly". The code is not without warning information when compiling through the compiler. Have you enabled all the warning messages that are available? If the language allows implicit declarations, do you compensate for the problems that may arise? If possible, all variables are defined as having a minimum scope. The reference points for each variable are as focused as possible. Do you do this for two consecutive references to the same variable, or for the entire lifetime of the variable? Does the control structure conform to the data type? Have all declared variables been used? Are the variables bound at the right time? That is, you consciously balance the flexibility of late binding with increased complexity. Each variable has and has only one purpose. The meaning of each variable is clear and has no implied meaning.

The name of the variable is complete and accurately expressed the meaning of the variable represented. The name is long enough that you don't have to think hard. If there is a calculation qualifier, is it placed behind the name? is the name used count or index to drop the num? Does the name of the circular small mark make sense? Have all the temporary variables been renamed to more meaningful names? When the Boolean variable is true, can the variable express its meaning exactly? The names in the enumeration contain prefixes or suffixes that can represent their classes. A named constant is named according to the abstract entity it represents, not the number it represents. Naming rules can distinguish between local data, class data, and global data. Rules can distinguish between type names, named constants, enumeration types, and variable names. The rule can represent the input parameters of a subroutine in a language where the compiler does not force detection of read-only parameters. Rules can be as compatible as possible with the standard rules of the language. Are the names formatted for readability? Whether to avoid a situation that is abbreviated just to save one character. All the words are abbreviated in the same way. Can the name be read out? Avoid using names that are easy to read and wrong. Do you have a description of the end name in the abbreviation table?

Do you want to avoid using cryptic values in the basic data type code? Does the code consider the exception of the 0 error? Is the type conversion obvious? If there are two different types of variables in a single statement, then the statement will be evaluated as you expect. Does the code avoid blending type comparisons? Can you work as expected by using an integer division expression? An integer expression avoids an integer overflow problem. Does the code avoid adding and subtraction operations on the order of magnitude difference for a specific large floating-point number? Does the code systematically prevent rounding errors from occurring? Does the code avoid making equal comparisons of floating-point values? Does the code avoid using mystery characters and strings? Did you avoid off-bye-one errors when using strings? Does the program use an extra Boolean variable to illustrate the conditional judgment? Does the program use additional Boolean variables to simplify the conditional judgment? The program uses enumerated types rather than named constants to improve readability and modifiable rows. When a variable cannot be represented with true and false, does the program replace the Boolean variable with an enumerated type? The test for an enumerated type detected an illegal value. Leave the first entry of the enumeration type as "illegal". A named constant is used consistently. No named constants are used in some places and the amount of text is used in other places. All array subscripts do not exceed the bounds of the array. The array reference does not appear to be off-by-one error. is the subscript order of all multidimensional arrays correct? In a nested loop, use the correct variable in the array subscript to avoid the subscript confusion.

Uncommon data types you use structs instead of simple variables to organize and manipulate related data. Have you considered creating a class instead of using a struct? All variables are local or class-wide. Unless absolutely necessary is the overall situation. Do you document all the global variables? Avoid the use of pseudo global data, which is a huge object that is passed around and contains messy data. Do you want to replace the global data with the accessor subroutine? Have access to its subroutines and data organized into the class? The accessor subroutine provides a layer of abstraction above the implementation of the underlying data type. All the associated accessor subroutines are in the same abstraction layer. Do you want to isolate the pointer operation in the subroutine? Does the pointer reference be valid. Or can the pointer be a dangling pointer? Does the code check its validity before using the pointer? Check for validity before using the variable that the pointer points to. Is the pointer set to empty when it is exhausted? In terms of readability, does the code use all the pointer variables you need to use? Are the pointers in the list released in the correct order? The program allocates a reserved memory reserve area so that it can gracefully exit when it runs out of memory. It is not possible to use pointers in the end if no other method is available.

Organization of Line Code code makes the dependencies between statements become apparent. is the name of the subroutine making the dependency relationship obvious? The parameters of the subroutine make the dependencies become apparent. If the dependencies are ambiguous, do you use annotations to describe them. Do you use "housekeeping variables" to check the sequential dependencies of key locations in your code? Is the code easy to read in the Top-down order? Related statements are organized together. Put the relatively independent statement groups into their own subroutines.

Use the normal path of the conditional statement code clearly. Does the If-then test handle the same branch correctly? Did you use the ELSE clause and explain it. Is the other word used right? With the IF and else words, they are not reversed. The normal condition that needs to be performed is maintained if and not in the else words. Does the if-then-else-if encapsulate complex judgments into Boolean functions? If-then-else-if first judge the most common situation. If-then-else-if judgment contains all the circumstances. If-then-else-if is the best implementation. Is it better than the case statement? Does the order of case clauses make sense. Each case clause is simple to operate. Did you call other subroutines when necessary? The case statement detects a real variable rather than intentionally making a variable to misuse the case statement. Is the default wording legal? Use the default words to detect and report unexpected situations. In C,c++ and Java, there is a break at the end of each case.

Does the loop replace the for loop with a while loop when appropriate? Is the loop created from inside to outside? Is it from the head of the loop into the loop? Is the initialization code directly in front of the loop? Is the loop an infinite loop or an event loop? The structure of the Adriano is clear. Avoid using code like for i = 1 to 9999. If this is a c++,c or Java for loop, then leave the loop header to the loop control code. The loop uses {} and its equivalent to enclose the loop body to prevent errors due to improper modification. Is there any content in the circulation body? Is he empty? Place the housekeeping focus on the beginning of the loop or at the end of the loop. Does the loop perform just one action like a well-defined subroutine? The cycle is short enough to glance at it. Does the loop have more than 3 layers of nesting levels? Extract the contents of a long loop into a separate subroutine. If the cycle is very long, then it is very clear. If this is a for loop, then the code in it is free to modify the looping subscript values. Whether to save the important cyclic subscript value in another variable, rather than using the loop subscript outside the loop body. is the loop subscript an ordinal type or an enumeration type, not a floating-point type? Does the name of the cyclic subscript make sense? The loop avoids the subscript crosstalk problem. Does the loop terminate at all possible conditions? If you set up some kind of security counter standard, does the loop use the security counter? is the exit condition of the loop clear? If you use a break or continue, do they use the right? Uncommon control structure Each child program only uses return when necessary. Does using return help enhance readability? Does the recursive subroutine contain code that stops recursion? The subroutine uses security counters to ensure that the subroutine stops. is recursion in only one subroutine? The recursive depth of the subroutine is within the limits of the capacity of the program stack to be satisfied. is recursion the best way to implement subroutines? Is it better than a simple iteration? Do you use Goto when you have a last resort? If Goto is used, is it just for readability and maintainability? If a goto is used in terms of efficiency, then the improvement in efficiency is measured and explained. At most, a goto label is used in a subroutine. All Goto jumps forward instead of backwards. Have all the goto labels been used?

Table-driven method have you considered using table-driven as an alternative to complex logic? Have you considered using table-driven as an alternative to complex inheritance structures? Have you considered storing the table data externally and reading it during run time so that you can change the data without modifying the code? If you can't access a table with a simple array index, you can extract the function of the machine acid access key into a separate subroutine instead of repeating the key value in your code.

General control problem expressions use True and false instead of 1 and 0. Do the Boolean and true and false comparisons be implicit? Does the comparison of numeric values be performed explicitly? There is no way to simplify an expression by adding new Boolean variables and using Boolean functions and decision tables. Boolean expressions are expressed in a positive form. Bracket pairing. Do you use parentheses where you want the parentheses to be clear? are the judgments written in the order of the axes? If appropriate, the decision in Java is in A.equals (b) mode, but not in the a==b way. Is the empty statement clearly stated? Can you simplify nested statements by using a partial if-then-else or case statement, by extracting the nested code into a separate subroutine, by replacing it with a more object-oriented design, or some other improved method? If there are more than 10 decision points for a subroutine, can you suggest a reason for not redesigning it?