Home  >  Article  >  Web Front-end  >  DIV CSS: Effective coding_html/css_WEB-ITnose

DIV CSS: Effective coding_html/css_WEB-ITnose

WBOY
WBOYOriginal
2016-06-24 12:29:18978browse

Reprinted from: http://blog.onlygrape.com/divcss/377

How to write CSS code more efficiently? This is a question that many web page makers and developers are concerned about. There is probably no magic that can guarantee that your style sheet will be reduced to a certain percentage instantly, but reasonable CSS coding and organization skills can indeed help you write clearer and more efficient code more efficiently. Naturally, style The reduction in table size also reduces download time.


1. Typesetting:

1. Add appropriate spaces between keywords and operators.

2. Add blank lines between relatively independent program blocks

3. Long statements, expressions, etc. should be written in multiple lines.

4. The divided new lines should be indented appropriately to make the layout neat and the statements readable.

5. Long expressions should be divided into new lines at low-priority operators, and the operators should be placed at the beginning of the new line.

6. If there are long expressions or statements in loops, judgments and other statements, they must be divided appropriately.

7. If the parameters in the function or process are long, they must be divided appropriately.

8. It is not allowed to write multiple short statements in one line, that is, only one statement in one line.

9. The beginning of a function or process, the definition of a structure, and the code in statements such as loops and judgments must be indented.

10. C/C language uses curly braces '{' and '}' to delimit a program block. When writing a program block, '{' and '}' should each occupy an exclusive line and be located in the same column. Left aligned with the statements that refer to them. The above indentation method must be used at the beginning of the function body, the definition of the class, the definition of the structure, the definition of the enumeration, and the programs in if, for, do, while, switch, and case statements.


2. Comments

1. Comments should be simple and clear.

2. Comment while writing the code, modify the code and modify the corresponding comments at the same time to ensure the consistency between the comments and the code.

3. Comment where necessary and the amount of comments should be moderate. The content of the annotation must be clear and concise, and the meaning must be accurate to prevent ambiguity in the annotation. Keep comments adjacent to the code they describe, that is, the proximity principle of comments.

4. Comments on the code should be placed adjacent to them above, not below.

5. Comments on the data structure should be placed adjacent to it, not below it; comments on each field in the structure should be placed to the right of this field; different fields in the same structure The comments should be aligned.

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

7. Global variables should have more detailed comments, including descriptions of their functions, value ranges, which functions or procedures access them, and precautions when accessing them.

8. There must be necessary annotation information at the head of each source file, including: file name; version number; author; generation date; module function description (such as functions, main algorithms, internal parts the relationship between this file and other files, etc.); list of main functions or processes and historical modification records of this file, etc.

9. There must be necessary annotation information in front of each function or procedure, including: function or procedure name; function description; input, output and return value description; calling relationship and called relationship description, etc.


3. Naming

1. Shorter words can be abbreviated by removing the "vowels";

2. Longer words can be abbreviated by removing the "vowels"; The priority of several symbols, and use parentheses to clarify the order of operation of expressions to avoid using the default priority.

3. Use Hungarian notation


4. Readability

1. Avoid using numbers that are difficult to understand and replace them with meaningful symbols.

2. Do not use difficult to understand and highly technical sentences.

3. Closely related codes in the source program should be as adjacent as possible.


5. Variables

1. Remove unnecessary public variables.

2. Construct public variables that only one module or function can modify and create, while other related modules or functions can only access them, to prevent multiple different modules or functions from modifying and creating the same public variable.

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

4. Clarify the relationship between public variables and the functions or procedures that operate the public variables, such as access, modification and creation, etc.

5. When transferring data to public variables, be very careful to prevent assigning unreasonable values ​​or going out of bounds.

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

7. Carefully design the layout and order of elements in the structure to make the structure easy to understand, save space, and reduce misuse.

8. The design of the structure should consider forward compatibility and future version upgrades as much as possible, and leave room for some possible future applications (such as reserving some space, etc.).

9. Pay attention to the principles and related details of specific languages ​​and compilers in handling different data types.

10. It is strictly prohibited to use uninitialized variables. Initialize variables when declaring them.

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


6. Functions and procedures

1. Try to limit the size of the function to less than 200 lines.

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

3. Write functions for simple functions.

4. The function of the function should be predictable, that is, as long as the input data is the same, it should produce the same output.

5. Try not to write 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 comments to explain in detail the function, value range and relationship between parameters of each parameter.

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

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

10. The function name should accurately describe the function of the function.

11. Avoid using meaningless or unclear verbs to name functions

12. The return value of a function should be clear and concise so that users cannot easily ignore error conditions.

13. Clarify function functions and implement function design accurately (rather than approximately).

14. Reduce recursive calls within the function itself or between functions.

15. When writing a reentrant function, if global variables are used, they should be protected by turning off interrupts and semaphores (i.e. P, V operations).


7. Testability

1. Before writing code, the methods and means of program debugging and testing should be designed in advance, and various debugging switches and corresponding Test code such as printing functions, etc.

2. Before conducting integration testing/system joint debugging, it is necessary to construct the test environment, test projects and test cases, and at the same time carefully analyze and optimize the test cases to improve testing efficiency.


8. Program efficiency

1. Always pay attention to the efficiency of the code when programming.

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

3. You cannot blindly pursue code efficiency, which will affect the correctness, stability, readability and testability of the software.

4. When programming, you must always pay attention to code efficiency; when optimizing code, you must consider everything.

5. Functions that are frequently called or have extremely high performance requirements must be carefully constructed or written directly in assembly.

6. Improve space efficiency by improving the division and organization of system data structures and optimizing program algorithms.

7. In multiple loops, the busiest loop should be placed at the innermost level.

8. Minimize loop nesting levels as much as possible.

9. Avoid judgment statements included in the loop body. The loop statements should be placed in the code block of the judgment statement.

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


9. Quality Assurance

1. Build software quality during the software design process. Code quality assurance priority principle

(1) Correctness means that the program must achieve the functions required by the design.

(2) Stability and security refer to the stability, reliability and safety of the program.

(3) Testability means that the program must have good testability.

(4) Standardization/readability, which means that the program writing style, naming rules, etc. must comply with the standards.

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

(6) Local efficiency refers to the efficiency of a certain module/sub-module/function.

(7) Personal expression/personal convenience, refers to personal programming habits.

2. Only reference your own storage space.

3. Prevent references to released memory space.

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

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

6. Prevent memory operations from going out of bounds.

7. Always pay attention to whether the expression overflows or underflows.

8. Carefully handle various error situations that the program may encounter.

9. At the beginning of the system operation, relevant variables and operating environment must be initialized to prevent uninitialized variables from being referenced.

10. At the beginning of the system operation, the consistency of the data loaded into the system must be checked.

11. It is strictly prohibited to change the relevant settings and configurations of other modules or systems at will.

12. The interface with other modules cannot be changed at will.

13. After fully understanding the system interface, use the functions provided by the system.

14. Always pay attention to confusing operators. When you finish programming, you should check these operators from beginning to end.

15. Do not use statements that are closely related to the hardware or operating system, but use recommended standard statements.

16. Recommendation: When using software development kits or controls provided by third parties, please pay attention to the following points:

(1) Fully understand the application interface, usage environment and precautions when using it .

(2) Don’t believe too much in its correctness.

(3) Unless necessary, do not use unfamiliar third-party tool packages and controls.


10. Code Compilation

1. When writing code, be sure to save it at any time and back it up regularly to prevent code loss due to power outages, hard disk damage, etc.

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

3. Reasonably design the software system directory to make it easier for developers to use.

4. Turn on all warning switches of the compiler and compile the program.

5. In the same project group or product group, compile switch options must 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. Unit testing should start by tracking each statement and observing changes in data flow and variables.

3. Cleaned, organized or optimized code must be reviewed and tested.

4. Code version upgrades must undergo strict testing.

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn