Team Geeks - Beta Code Standards

Team_Geeks 团队账号 2023-12-06 23:03:16

Which course does this assignment belong to	230 1-MUSE Community-CSDN Community Cloud
Assignment Requirement	Teamwork-beta Sprint-CSDN Community
Team name	Geeks
The goal of this assignment	team's code standards

Code Standards

Statement writing

If the parameters in the function or procedure are long, they should be divided appropriately.
Align using only the space bar, not the TAB key.
The code in all files should be indented, and the left and right parentheses should correspond to each other.
In JS, JSON, and wxss files, the left parenthesis (such as "{, [", etc.) Should be placed after the code, and the right parenthesis (such as "},]", etc.) Should be indented with the code.
When more than two keywords, variables, and constants are operated equivalently, spaces should be added before, after, or before and after the operators between them; Non-equivalent operations should not be followed by a space if it is a closely related immediate operator (such as->).

Note

In general, the effective annotation amount of the source program must be more than 20%.
Write comments while writing the code, and modify the corresponding comments while modifying the code to ensure the consistency between the comments and the code. Comments that are no longer useful should be deleted.
The content of the annotation should be clear, clear and accurate, so as to prevent the ambiguity of the annotation.
Avoid using abbreviations in notes, especially very abbreviations.
The comment shall be similar to the code it describes. The comment on the code shall be placed above or to the right (the comment on a single statement). It shall not be placed below. If it is placed above, it shall be separated from the code above by a blank line.
Data structure declarations (including arrays, structures, classes, enumerations, etc.) must be annotated if their names are not sufficiently self-annotated. Comments on a data structure should be placed adjacent to and above it, not below it; comments on each field in the structure are placed to the right of the field.
The global variable shall be annotated in detail, including the description of its function, value range, which functions or procedures access it, and matters needing attention during access.
Annotations are indented as described.
Comments must be written for variable definitions and branch statements (conditional branches, loop statements, etc.). Avoid inserting comments in the middle of a line of code or expression.
Annotate the function and intention level of the code to provide useful and additional information.
The annotation shall consider the readability of the program and the layout of the appearance. If the language used is both Chinese and English, it is recommended to use more Chinese unless it can be expressed in very fluent and accurate English.

Identifier naming

The name of the identifier should be clear, clear and have a clear meaning. At the same time, complete words or abbreviations that can be understood by everyone should be used to avoid misunderstanding.
If special conventions or abbreviations are used in naming, notes shall be provided.
Your own unique naming style should be consistent from beginning to end and should not be changed back and forth.
For variable naming, it is forbidden to take single character (such as I, J, and K..). It is suggested to indicate its variable type and data type in addition to specific meaning, but it is allowed to use I, J, and K as local loop variables.
The naming convention must be consistent with the system style used and be unified in the same project. For example, use the UNIX style of all lowercase and underline or the way of mixed uppercase and lowercase. Do not use the way of mixed uppercase and underline. It is allowed to use m _ and G _ as special identifiers, such as identifying member variables or global variables, followed by the way of mixing uppercase with lowercase.
Don't use numbers or strange characters to define identifiers unless necessary.
Use the correct antonym to name variables with mutually exclusive meanings or functions with opposite actions.
With the exception of special applications such as compilation switches/header files, avoid definitions that begin and end with an underscore, such as _ EXAMPLE _ TEST _.

Readability

Pay attention to the priority of operators, and use parentheses to clarify the operation order of expressions, so as to avoid using the default priority.
Closely related codes in the source program should be adjacent as far as possible.
Don't use difficult and skillful sentences unless it is necessary.

Variables, structures

Remove unnecessary public variables.
Clarify the relationship between a public variable and the function or procedure that operates the public variable, such as access, modification, and creation.
When passing data to public variables, be very careful to prevent the occurrence of unreasonable values or out-of-bounds.
Prevent local variables from having the same name as public variables.
Do not use an uninitialized variable as an rvalue.
Use strictly formalized, portable data types, and try not to use variables that are closely related to specific hardware or software environments.
The function of the structure should be single, which is an abstraction for a transaction.
Don't design a comprehensive and flexible data structure.
The relationship between different structures should not be too complicated.
The number of elements in the structure should be moderate. If the number of elements in the structure is too large, it can be considered to combine the elements into different sub-structures according to a certain principle to reduce the number of elements in the original structure.
Carefully design the layout and order of elements in the structure to make the structure easy to understand, save space and reduce misuse.
The design of the structure should consider forward compatibility and future version upgrade as far as possible, and reserve room for some possible future applications (such as reserving some space).
Name the custom data type appropriately and make it self-descriptive to improve code readability. Pay attention to the unification of naming methods in the same product.

Functions, procedures

Handle the error return code of the called function carefully and comprehensively.
In the same project team, it should be clearly specified whether the function caller or the interface function itself should be responsible for checking the validity of the interface function parameters. By default, the function caller is responsible for checking the validity of the interface function parameters.
Avoid designing multi-parameter functions, and remove unused parameters from the interface.
Try not to write functions that depend on the internal implementation of other functions.
The function should be predictable, that is, it should produce the same output as long as the input data is the same.
Check the validity of all parameter inputs of the function.
Check the validity of all non-parameter inputs of the function, such as data files, public variables, etc.
The function name should accurately describe the function.
The return value of the function should be clear and clear, so that the user can not easily ignore the error situation.
When calling a function to fill in parameters, unnecessary default data type conversion or mandatory data type conversion should be minimized.
Avoid unnecessary statements in functions and prevent junk code in programs.
Prevent unrelated statements from being placed in a function.
Reduce recursive calls within or between functions.
For a function that provides a return value, it is better to use its return value when referring to it.

Measurability

In the same project group or product group, the format of the information string printed by debugging shall be unified. At least the module name (or source file name) and line number must be included in the information string.
While programming, select appropriate test points for unit testing, carefully construct test codes and test cases, and give clear comments. The test code part shall be a sub-module (in the module) to facilitate the installation and removal of the test code in the module (through the commissioning switch).
Use assertions to find software problems and improve code testability.
Use assertions to check for illegal situations that should not occur when the program is running normally but may occur during debugging.
Assertions cannot be used to check for error situations that are certain to occur in the final product and must be handled.
Add explicit comments to more complex assertions.
Confirm the parameters of the function with the assertion.
Use assertions to ensure that undefined features or functions are not used.
Assertions and other debugging codes shall be removed from the formal software product (that is, relevant debugging switches shall be turned off).
Write an error-proofing program, and then declare the error with an assertion after handling the error.

Program efficiency

Always pay attention to the efficiency of the code when programming.
Improve the code efficiency on the premise of ensuring the correctness, stability, readability and testability of the software system.
Local efficiency should serve the global efficiency, and the improvement of local efficiency should not affect the global efficiency.
Improve the space efficiency by improving the division and organization of the system data structure and optimizing the program algorithm.
Carefully analyze and optimize the relevant algorithms.
Analyze and optimize the division and organization of the functions in the module, improve the organizational structure of the functions in the module, and improve the efficiency of the program.
Don't spend too much time trying to improve the efficiency of function code that is not called very frequently.
On the premise of ensuring the quality of the program, the space efficiency is improved by compressing the amount of code, removing unnecessary code and reducing unnecessary local and global variables.
In multiple loops, the busiest loop should be placed in the innermost layer.
Avoid containing judgment statements in the loop body. The loop statement should be placed in the code block of the judgment statement.
Try to replace division with multiplication or other methods, especially division in floating-point operations.
Don't go for tight code.

Quality Assurance

Build software quality in the process of software design.
Priority principle of code quality assurance.
Prevent references to memory space that has been freed.
Prevent memory operation from crossing the boundary.
Carefully deal with all kinds of errors that the program can encounter.
At the beginning of system operation, check the consistency of the data loaded into the system.
It is strictly prohibited to change the relevant settings and configurations of other modules or systems at will.
Fully understand the interface of the system before using the functions provided by the system.
Do not change the interface with other modules at will.
Always be aware of confusing operators. When you have finished writing a program, you should check these operators from beginning to end to prevent spelling errors.
When using variables, pay attention to their boundary values.

Code editing, compilation, review

Turn on all alarm switches of the compiler to compile the program.
Check the code by means of code walk-through and review.
Before testing the product, the testing department shall conduct spot check and review on the code.
When writing the code, pay attention to saving it at any time and backup it regularly to prevent the loss of the code due to power failure, hard disk damage and other reasons.
In the same product software (project group), it is better to use the same editor and use the same setting options.
Reasonably design the software system directory to facilitate the use of developers.
Some statements generate an alarm after compilation, but if you think it is correct, you should remove the alarm information by some means.

Code testing, maintenance

Unit testing requires at least statement coverage.
At the beginning of the unit test, track each statement and observe the changes of data flow and variables.
The cleaned, tidied, or optimized code should be reviewed and tested.
Correct errors immediately and record them.
Any modification of the official version of the software shall be documented in detail.
Analyze the errors that disappear automatically and find out how the errors disappear.
The problem should not be solved by "trying", but the root cause of the problem should be found.
Insist on thoroughly unit testing the code at the coding stage, and don't wait for later testing to find problems.
Remove the randomness of code operation (such as removing useless data and code and preventing and paying attention to the "internal registers" in the function as much as possible), so that the results of function operation can be predicted and the errors can be reproduced.

...全文