DIV + CSS: how to write code to make it more efficient, divcss

DIV + CSS: how to write code to make it more efficient, divcss

How can I write CSS code to make it more efficient? This is a concern of many web page makers and developers. There is no magic. You can make sure that your style sheet is reduced to, but the CSS coding and organization skills are reasonable, it can indeed help you write clearer and more efficient code more efficiently. Naturally, you can reduce the size of the style sheet and reduce the download time.

I. Layout:

1. Add spaces between keywords and operators.

2. Empty lines are added between relatively independent blocks.

3. Long statements and expressions should be written into multiple lines of books.

4. The new lines should be indented to make the layout neat and the statement readable.

5. Long expressions should divide the new line at the lower-priority operator, and the operator should be placed at the beginning of the new line.

6. If a long expression or statement exists in statements such as loop and judgment, an appropriate division is required.

7. If the parameters in a function or process are long, appropriate division is required.

8. You are not allowed to write multiple phrase sentences in one row, that is, only one statement can be written in one row.

9. The code in the statements such as the start of a function or process, the definition of the structure, and the cycle and judgment should adopt the indent style.

10. C/C ++ uses braces '{' and '}' to define a block, when writing a program block, '{' and '}' should each have an exclusive row in the same column and be left aligned with the statements that reference them. At the beginning of the function body, the definition of the class, the definition of the structure, the definition of enumeration, and the programs in the if, for, do, while, switch, and case statements must adopt the above indent method.

Ii. Notes

1. Annotations should be simple and clear.

2. Write and annotate the code, modify the code, and modify the corresponding comments to ensure the consistency between the comments and the code.

3. Make comments where necessary, and the comments should be moderate. The content of the comment must be clear, clear, and accurate, so as to prevent the ambiguity of the comment. Keep comments adjacent to the code described by them, that is, the proximity principle of comments.

4. Comments to the code should be placed in adjacent locations above the code, and should not be placed below.

5. The comment on the data structure should be placed above the adjacent position and not below; the comment on each field in the structure should be placed on the right of the field; annotations for different domains in the same structure must be aligned.

6. Comments of variables and constants should be placed on the adjacent positions or the right side above them.

7. global variables should be annotated in detail, including descriptions of their functions, value ranges, functions or processes to access them, and precautions for access.

8. Make necessary comments in the header of each source file, including the file name, version number, author, and generation date; module function description (such as functions, main algorithms, relations between various internal parts, relations between the file and other files), list of main functions or processes, and historical modification records of this file.

9. Make necessary comments before each function or process, including the function or process name, function description, input, output, and return value description; call link and description of called Link.

Iii. Naming

1. Short words can be abbreviated by removing the "vowel;

2. The priority of the first few characters of a long word that can be obtained, and the operation sequence of the expression is defined with parentheses to avoid using the default priority.

3. Using Hungarian notation

Iv. Readability

1. Avoid using numbers that are hard to understand and use meaningful identifiers instead.

2. Do not use difficult and skillful statements.

3. Code closely related to the source program should be as adjacent as possible.

V. Variables

1. Remove unnecessary public variables.

2. construct public variables that only one module or function can be modified or created, while other related modules or functions can only access, this prevents multiple different modules or functions from modifying or creating the same public variable.

3. Carefully define and clarify the meaning, function, value range, and relationship between public variables.

4. clarify the relationship between a public variable and a function or process that operates the public variable, such as access, modification, and creation.

5. When transferring data to public variables, be very careful to prevent improper value or out-of-bounds.

6. prevent local variables from having the same name as public variables.

7. carefully design the layout and arrangement sequence of elements in the structure to make the structure easy to understand, save space occupation, and reduce misuse.

8. The structure should be designed with forward compatibility and later version upgrade as much as possible, and leave room for some potential applications in the future (such as reserve some space ).

9. Pay attention to the principles and relevant details of the specific language and compiler for processing different data types.

10. It is strictly prohibited to use uninitialized variables. Declare the variable and initialize the variable.

11. During programming, pay attention to forced conversion of data types.

Vi. functions and processes

1. The function size should be limited to less than 200 rows.

2. It is best for a function to complete only one function.

3. Compile functions for simple functions.

4. functions should be predictable, that is, the same output should be generated if the input data is the same.

5. Try not to compile functions that depend on the internal implementation of other functions.

6. Avoid designing multi-parameter functions and Remove unused parameters from the interface.

7. Use annotations to describe the role, value range, and relationship between parameters.

8. Check the validity of all parameter input of the function.

9. Check the validity of all non-parameter inputs of the function, such as data files and public variables.

10. The function name should accurately describe the function.

11. Avoid using meaningless or ambiguous verbs for function naming.

12. The return value of the function should be clear and clear, so that users cannot easily ignore errors.

13. Define function functions and implement function design accurately (rather than approximation.

14. Reduce recursive calls between functions.

15. When writing A reentrant function, if a global variable is used, it should be protected by means of clearance interruption and semaphores (P and V Operations.

VII. Testability

1. Before writing the code, we should design the methods and means for program debugging and testing in advance, and design various debugging switches and corresponding testing codes, such as printing functions.

2. Before integrated testing/system joint debugging, you must construct the test environment, test items, and test cases, and carefully analyze and optimize the test cases to improve the test efficiency.

VIII. Program Efficiency

1. Pay attention to code efficiency during programming.

2. Improve code efficiency while ensuring the correctness, stability, readability and testability of the software system.

3. Do not blindly pursue code efficiency, but affect the correctness, stability, readability, and testability of the software.

4. Pay attention to code efficiency at any time during programming; Be careful when optimizing code.

5. carefully construct or directly compile functions with frequent calls or extremely high performance requirements using assembler.

6. Improve the system data structure division and organization, and optimize program algorithms to improve space efficiency.

7. In multiple cycles, the busiest cycle should be placed in the innermost layer.

8. Reduce the number of nested loops as much as possible.

9. To avoid the inclusion of judgment statements in the loop body, the circular statements should be placed in the code block of the judgment statement.

10. Try to use multiplication or other methods instead of division, especially in floating point operations.

IX. Quality assurance

1. Build Software Quality in the software design process. Code Quality Assurance priority principle

(1) Correctness refers to the function that the program needs to implement the design requirements.

(2) stability and security means that the program is stable, reliable, and secure.

(3) testability means that the program should have good testability.

(4) specification/Readability: The program Writing Style and naming rules must comply with the specifications.

(5) global efficiency refers to the overall efficiency of the software system.

(6) Local Efficiency refers to the efficiency of a module, submodule, or function.

(7) personal expressions/personal convenience refer to personal programming habits.

2. Only reference your own storage space.

3. Prevent reference of released memory space.

4. The memory allocated in the process/function should be released before the process/function exits.

5. The file handle applied in the process/function (used to open the file) should be closed before the process/function exits.

6. prevent out-of-bounds memory operations.

7. always pay attention to whether the expression will overflow or overflow.

8. handle all kinds of errors encountered by the program.

9. When the system is running, initialize the relevant variables and runtime environment to prevent uninitialized variables from being referenced.

10. Check the consistency of the data loaded into the system at the beginning of the system operation.

11. You are prohibited from arbitrarily changing the settings and configurations of other modules or systems.

12. Do not change the interface with other modules at will.

13. Use the functions provided by the system after fully understanding the system interfaces.

14. always pay attention to confusing operators. After the program is compiled, check the operators from the beginning to the end.

15. Use the recommended standard statement instead of statements that are highly related to hardware or operating systems.

16. Suggestion: pay attention to the following points when using third-party software development kits or controls:

(1) fully understand the application interface, use environment, and precautions during use.

(2) do not trust its correctness too much.

(3) do not use unfamiliar third-party toolkit and controls unless necessary.

10. code compilation

1. When writing code, you must save the code at any time and regularly back up the code to prevent code loss due to power failure or hard disk damage.

2. In the same project group, it is best to use the same editor and use the same setting options.

3. Properly design the software system directory for developers to use.

4. Enable all alert Switches of the compiler to compile the program.

5. In the same project group or product group, the compilation switch option should be unified.

6. Use tool software (such as Visual SourceSafe) to maintain the code version.

11. Code testing and maintenance

1. Unit Testing requires at least statement coverage.

2. At the beginning of unit test, we need to track each statement and observe the changes of data streams and variables.

3. Code after cleaning, sorting, or optimization should be reviewed and tested.

4. Code version upgrades must be strictly tested.