4.3 code review
Code standard. The coding standard is widely accepted and can be used as a coding practice set of the working model. Good coding standards will effectively help you avoid developing potentially dangerous code to help prevent defects. For example, those methods that should be avoided in the coding criteria, the predetermined number cycle entry or instructions are initialized variables, and avoid bad variables. The coding standard can also be effectively unified and standardized for overall development activities. When other developers join the project, they can adapt to this. Codes will also become more standardized.
Table 4.5 C coding standard
the goal
Guidance C program development
Program head
Program head format
All programs should start from a descriptive beginning
/ ************************************************** ****************** /
/ * Program Assignment: Director * /
/ * Name: Your name * /
/ * Date: Program Development Start Date * /
/ * DESCRIPTION: A simple description of the program function * /
/ ************************************************** ****************** /
List of content
Content distance
A summary of a list
/ ************************************************** ****************** /
/ * Listing Contents: * /
/ * Reuse instruction (Reuse Guide) * /
/ * Incrudes (including) * /
/ * Class Declaroions * /
/ * CDATA * /
/ * ASET * /
/ * Source Code In C (Source code written with C): /classes/cdata.cpp: * /
/ * CDATA * /
/ * CDATA () * /
/ * EMPTY () * /
/ ************************************************** ****************** /
Reuse guidance
Example
Describe how to use the program. Provides an explanation format, parameter value, and a range of parameter; provide a warning for illegal values, overflow conditions, or other potential possibilities such as abnormal operations.
/ ************************************************** ****************** /
/ * Reuse instruction (Reuse Guide) * /
/ * Int printline (char * line_of_character) * /
/ * Purpose: Picture, 'line_of_character', located in the same printing line * /
/ * Limit: The wire length is up to line_length * /
/ * RETURN: 0 If the printer is not ready * /
/ * Else 1 * /
/ ************************************************** ****************** /
Identifier
Identifier example
All variables, function names, constants, and other identifiers are all named with descriptive. Avoid abbreviations or variable names with only one letter.
INT Number_of_students / * This identifier is good * /
INT X4, J, FTAVE / * This identifier is not good * /
Comment
Good comment
Bad comment
Program main body
Example
Encoding, documentation should be sufficient to help readers understand their functions;
Note and the purpose of the encoding should also be explained;
Comment on variable declarations indicating that the purpose of this variable is indicated.
If (record_count> limited) / * All records have been processed * /
If (record_count> limited) / * Check if the record_count exceeds the restriction * /
There should be a comment before the program main body to describe the processing made by the following portions.
/ ************************************************** ****************** /
/ * The following program part will prosecute the contents of "grades" and will calculate the average of class scores. * /
/ ************************************************** ****************** /
blank area
In order to increase the readability of the program, you should leave a certain space when writing;
There is at least one hollow line between each program structure.
indentation
Indentation example
There should be indentation between brackets between different levels;
Each start bracket and termination parentheses should occupy a row.
While (MISS_DISTANCE> Threshold)
{
Success_code = move_robot (target_location);
IF (Success_code == Move_failed)
{
PRINGF ("The Robot Move Has Failed./N")
}
}
capital
Capital example
All definitions should be capitalized;
All other identifiers and reserved values should be lowercase;
The output information for the user can be large, lower-write, so that the user is clear.
#define default_number_of_students 15int class_size = default_number_of_students;
Other types of code reviews. In software organizations, a common way is to review, and several engineers review procedures. Good organizational peer reviews generally discovers 50% to 70% of the defects in procedures. Although mutual investment requires a lot of time, it can effectively discover defects, because engineers are often difficult to find their design errors. They created this design until the program should be complete, even if the concept is flawed, it is often difficult to find it. Check if this can help them overcome these issues. For a large project, the best inspection strategy is to make a personal code review and then compile, and then check in any test.
Care work is rewarded. When the engineer feels quality responsibility to the program developed, he will not rely on the compiler or other tools to discover defects. A comprehensive code review takes time, but it saves more time than spending more, and can produce better products.
