Software Development specifications summarized by the predecessors

In order to improve the quality of software development, reduce the development cycle, enhance the reusability and accessibility of code, make the software easy to maintain, and facilitate communication and collaboration among developers, the development specifications are summarized for reference.

I. Principles:

1. Software Engineering
2. Modularization
3. Simple and not complex
4. emphasize teamwork
5. emphasize innovation and Characteristics

II. Specific specifications:

1. Naming rules
The Hungary naming method should be used whenever possible, and the variable name or function name should use uppercase characters to distinguish each part for memory and reading. Such as bPatchMinute and DeleteDirInfo (). Global (including class) variables use long names, while local variables use short names.
M _ should be added before the class member variables, and g _ should be added to the global variables. Only the variables related to this module should be added with l _, followed by the variable type.
Integer: n, I
Long Integer: l
Unsigned integer: u
Unsigned long integer: dw
Character: ch
Boolean: B
Floating Point: f
Double-precision floating point: d
String: str, lpsz, sz, p, lp, ac,
Pointer: p
Byte pointer: pb
Unsigned pointer: pv
Character pointer: lpsz
Integer pointer: lpn
File pointer: fp
For example:
M_nTotalNum, m_strPath, m_bRcving, m_fPrice, g_lOpenDate, g_dwCardNo, lpszNameStr, lpnSysDoomType, uMsgID, m_pProgress

Local variables should be easy to understand and concise, and common variables should be used, such
Num, nCount, I, j, k, n, len, pos, offset, nReadNum, index, nRet, ret, string, filename
Temporary variables, such as ltmp, ftmp, tmpStr, tempStr,

The function name should also be known. Such as CalcAllDataStyle (), ReadDocDataFromTime (), GetIndexInfo ()
Common functions
Init, OpenAll, Create _, Get _, Set _, Read _, Load _, Write _, Start _, Stop _, Check _, Test _, Fill _, Process _, sort _, Do _, Select _, Is _, Exist _, _ Ex.

Macro naming and typedef definition types should be detailed to avoid duplication, and should be capitalized, such

# Define DEL_EMPTY (a) {if (a) {delete a; a = NULL ;}}
# Define SUCCESS 0
# Define FAIL-1

Typedef struct
{
Char lpzSource [100];
Char lpzTitle [100];
Char lpzURL [194];
Short nType;
Long npos;
Long nlen;
} ATTBODY, * LPATTBODY; (LP is added before the pointer)

Custom messages start with WM_USER
# Define MYAPP_MESSAGE WM_USER + 0x1001

2. Code specifications
Some variables or functions that are hard to understand should be annotated. obscure code should be annotated and the purpose description of the file should be included at the beginning of the file. Make sure that the annotation is consistent.

The Code organization should be clear. for example, {,}, (,), if, else, do, while, for, and case, the code should be neatly organized with less space and Tab keys used for indentation. Variables must be defined in a centralized manner, and functions must be separated by empty rows. The number of empty rows in a program is best between 8% and 16%. Multi-State functions are put together with functions with similar functions.

The Code should be concise, clear, and all that happened. Our goal should be to write the clearest code, not the most clever code. For example, if it is an MFC multi-document program, you must write code strictly according to the framework generated by the program. Try to use the functions provided by the compiler without having to write them later. For example, the system already has the qsort function, which can be used for sorting directly.

Some public code should pay attention to the ease of Transplantation of multiple platforms. It is best to use standard C.

The Code should be reused carefully and relevant code should be copied. Note that the Code may not be suitable for your application.

Delete functions or variables that have never been used, and delete the code lines commented out in a large space to avoid confusing programs.

3. Organization specifications of engineering documents
A project usually contains many files (*. h ,*. cpp ,*. inc ,*. lib, resource files, etc.), to add files to the project or delete files in the project should be careful, to avoid engineering damage. Files or classes that do not work in the project should be deleted, and non-engineering files under the project directory should also be removed to keep the project clean and avoid confusion and difficulty in management. If there are many engineering documents, they should be classified.

In the VC environment, we recommend that you add all common header files to stdafx. h, and embed stdafx. h at the beginning of each cpp. Avoid cross-reference of header files. If there is a severe cross-reference, use the class declaration as appropriate.

Extract modules with strong independence into DLL, control, or COM components. This module can be compiled and tested separately, and its reusability is also enhanced.

A relatively large project should have certain message interfaces or plug-in interfaces.

The project version must be strictly controlled. The version format is xx. If necessary, use the Build count or date. The higher version is compatible with the usage, data, or protocol of the lower version as much as possible.

The compilation macro definition and engineering parameter settings of the project should be correct. Check whether the engineering parameters are correct for each new project.
We recommend that you use 1-byte alignment.

Engineering documents should be backed up frequently, and the backup date and major functions should be specified during Backup.

4. Class Organization specifications
Class generally has two files, one header file and one implementation body CPP.

Classes strive to encapsulate and strictly differentiate public, private, protect, and other scopes. If a function has a great relationship with this class, it can be used as a static member function of this class, methods and techniques that destroy class encapsulation, such as using less or using friend functions. If some structures or macros are only related to this class, they can be defined in the Class header file.

Class member variables should be assigned an initial value in the constructor or initialization function. The pointer is NULL in the constructor. DEL_EMPTY is used for Structure Analysis to avoid Memory leakage.

5. User interface specifications
There are four types of user interfaces: dialog box, single document interface, multi-document interface, and other interfaces

The dialog box should be easy to use and concise, and the font and control should be properly organized and matched. It should be simple and not complex. The focus and Tab order of each control should be emphasized, and the keyboard should be supported as appropriate in application scenarios. While being concise and easy to use, we strive for personalization and better design. The style of each program dialog box must be consistent.

Single Document and multi-Document Interface programs can be very powerful and easy to expand and manage. The menu, toolbar, and status bar must have their own characteristics. A menu is displayed by category. If necessary, multiple menus are designed. You can right-click an important window or area to perform common operations. Put the most common operation buttons on the toolbar, and change the buttons dynamically if necessary. The status bar shows enough useful information.
The message master is in Mainframe, and the single-document master can also be in View. All dialog box pop-up or non-modal dialog box controls are completed in the master window, specific data processing is stored in a separate file or designed as a class. In the App class, you can read and write Ini, define and analyze data objects, assign values to global variables, perform initial calculations, and save disks. The OnDraw and GDI diagrams of each view should use the memory bitmap method as much as possible to avoid flickering.

Other functions include ATL, console, embedded program interface, and plug-ins in other containers such as IE. Such programs may be implemented using COM components instead of MFC.

6. troubleshooting and Bug debugging methods
Diligent and good at asking. Without interrupting normal work, developers should help each other and brainstorm. Maybe your problems or bugs are the lessons of others.

Request answers from various channels. Professional books, teaching materials, journals, electronic documents, international standard documents, RFC, and other professional websites, forums, and expert groups on the Internet.

There are always some reasons for the emergence of bugs. Please look for them calmly and do not always stick to a small part. You may be confused by another idea and perspective. Use auxiliary development or debugging tools, such as Spy ++, Process Viewer, and system monitor.

Broaden your knowledge. Learn more about other programming languages, database knowledge, compilation principles, network protocols, etc. Be familiar with hardware devices, underlying assembly, and digital logic circuits. Use and speculate on other software functions and interfaces to build innovative and distinctive functional software.

3. Some habits:

I think it is a good habit:

1. if (0 = GetDataType (...)) Than if (GetDataType (...) = 0) Okay. Even if I mistakenly write = As =, an error will be reported at the compilation layer.
2.
# Define MAX_DOWNLOADNUM 20
Struct DownInfo m_DownInfo [MAX_DOWNLOADNUM];
In the code, try not to use specific size values and define them as macros for future maintenance.
3.
CUSTXG_CONTABLE g_lpCustCon [] =
{
{"Numeric string 1", C_ZGB, C_CUSTJBM, C_VT_FBJ, "Ten Thousand "},
{"Numeric string 2", C_ZSZ, C_CUSTJBM, C_VT_FBJ, "Ten Thousand "},
...
{"Numerical ratio", C_WTB, C_CUSTHQ, C_VT_FBJ, "% "}
};
Int g_nCustNum = sizeof (g_lpCustCon)/sizeof (CUSTXG_CONTABLE );
G _ nCustNum automatically adapts to the g_lpCustCon size.
4.
The short GetInputType (const char * lpzInput) defined by the function is better than short GetInputType (char * lpzInput) to prevent lpzInput from being damaged in the function body.
5.
The protocol header is defined:
Typedef struct tagDataHeader
{
Struct {
Unsigned char Version: 4;
Unsigned char HeaderFlag: 2;
Unsigned char Reserved: 2; // reserve Bits
} Info;
Long nOther;
Long Reserved; // retain 4 bytes
} DATAHEADER;
Some reserved fields are defined for future extension.
6.
Assign an initial value to the variable during definition, and determine to release all variables when the class destructor or program exits.
7.
The encoding space must be fully reserved. Pay attention to scalability when coding.

I think it is a bad habit:

1. The code is "+ 2", "+ 4", instead of "+ sizeof (short)", "+ sizeof (int )".
2. filename [40] instead of filename [MAX_PATH].
3. Do not release the GDI resources after use, and do not Select the bitmap or brush after use. This will cause the loss of system Gdi resources or memory leakage.
4. Use unsigned variables in large quantities. Unsigned variables are prone to errors, even endless loops, and should be used as little as possible.
5. Use malloc, free do not use new, delete, and use realloc in large quantities. New and delete are standard C ++ syntaxes with strong versatility. realloc can easily cause memory jitter.
6. # define square (x) * (x)
The macro body should be enclosed in parentheses. Otherwise, problems may occur. For example, 1/square (x) will be replaced by 1/(x) * (x)