http://www.itbookreview.net/itbookreview/view_paper.asp?paper_id=20
Some software development specifications I summarize Autfresh
Original author name allfresh
Article original source http://www.allfresh.net/
text
In order to improve software development quality, reduce the development cycle, enhance the reusability and readability of code, so that the software is easy to maintain, and the developers are easy to communicate and collaborate, and they will summarize the development specification and consider.
One. in principle:
1. Software engineering
2. Modularity
3. Simple and not complicated
4. Emphasize teamwork
5. Emphasize innovation and features
two. Specific specification:
1. Naming conventions
Naming should try to use uppercase characters in the Hungarian nomenclature, variable name, or function name to distinguish between individual parts to make memories and read. Such as bpatchminute, deletedirinfo (). The global (including the class) variables with a long name, local variables.
Before the class member variable should be added to M_, global variables plus G_, only with the variable related to this module, plus L_, followed by the type of variable.
Integer: n, i
Long integer: L
No symbol integer: U
No symbol length: 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
No symbolic pointer: PV
Character pointer: LPSZ
Integer pointers: lpn
File pointer: fp
Such as:
M_NTotalNum, M_StrPath, M_Brcving, M_FPRice, G_LOPENDATE, G_DWCARDNO, LPSZNAMESTR, LPNSYSDOOOOOOOMTYPE, UMSGID, M_PPROGRESS
Local variables should be as simple as possible, using common variables, such as
Num, N, N, Len, Pos, Offset, Nreadnum, Index, NRET, RET, STRING, FILENAME
Temporary variables such as LTMP, FTMP, TMPSTR, TEMPSTR,
The function name should also be seen. 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.
The macro name and Typedef definition type should be detailed, avoid repeating, all written, such as
#define del_empty (a) {if (a) {delete a; a = null;}}
#define surcess 0
#define fail -1
Typedef struct
{
Char lpzsource [100];
Char lpztitle [100];
Char lpzurl [194];
Short NTYPE;
Long NPOS;
Long Nlen;
} Attbody, * lpattbody; (1 Pointer plus LP)
Custom message starting from WM_USER
#define myapp_message wm_user 0x1001
2. Code specification
Some of the variables or functions that are not easy to understand should be annotated, and the unknown code must be annotated, and the purpose of this file is at the beginning of the file. Be sure to keep your comment consistency. The code organization should be clear, {,}, (,), if, else, do, while, for, case, etc. should be neat, less space, and indent all Tab keys. The definition of the variable is to concentrate, and the function is separated from the function, and the number of spaces in one program accounts for 8% -16%. The polymorphism functions are set together.
The code should be concise, clear and tell everything happening, our goal should be the clearest code, not the most clever code. For example, if it is an MFC multi-document program, it is necessary to write code in strict accordance with the framework generated. Try to use the functions already provided by the compiler, don't have to worry about it. For example, the system already has a QSort function, which can be used directly.
Some public code should pay attention to the multi-platform easy porting, it is best to use standard C.
The reuse of the code should be carefully, to copy the relevant code, pay attention to that code may not suit your application.
Deleting a function or variable that has never used it, the code line that the large space comment is also deleted, so as not to make the program troubles.
3. Project document organizational specification
A project often contains many many files (* .h, *. CPP, *. Inc, *. Lib, resource files, etc.), which should be cautious to join files or delete projects to the project to avoid damage to engineering. Documents or classes in the project should be deleted, and non-engineering documents in the project catalog should also be removed, keeping engineering clean, avoid confusion is difficult to manage. If there are many project files, it should be classified.
In a VC environment, it is recommended to put all common headers in stdafx.h, and STDAFX.H is embedded at each CPP. Avoid cross-references of the header file, if there is a serious cross-reference, properly use the declaration of the class.
Puminate the modules that are relatively independent, make DLLs, controls, or COM components, which can be written and tested separately and enhance their reusability.
A relatively large engineering should have a certain message interface or plug-in interface.
The version of the project is strict, the version format is XX.xx.xx, and the number of builds or date is used if necessary. High versions are as compatible with low versions, data or protocols.
The engineering compilation macro definition and engineering parameter settings should be correct, and the engineering parameters should be checked correctly when making a new project.
It is recommended to be 1 byte alignment.
Engineering documents should be backed up frequently and indicate the date and the main increased function when backing up.
4. Class organization specification
Class generally have two files, one header file, one realizing CPP.
Class combined with good packaging, strictly distinguishing between public, private, protect, etc. If a function has a great relationship with this class, it can be used as a static member function, no need to destroy class encapsulation or less use. skill. If some structures or macros are related to this class, they can be defined in the class header file.
The member variable of the class should be assigned in the constructor or initialization function. The pointer assigns NULL in the constructor, and Del_empty is destructured to avoid memory leakage.
5. User interface specification
There are four major types of user interface: dialog, single document interface, multi-document interface, other interface
The dialog box is easy to use and simple, the organizers of fonts and controls must be decent, simple and incapacitated, the focus of each control, the Tab order, etc. should be appropriate, and the keyboard should be appropriately supported by the application. Under the premise of simple and easy to use, strive to be personalized, design more friendly. The style of each dialog of the program should be consistent.
The program function of a single document and a multi-document interface can be made strong and easy to expand and manage. Some of the menus, toolbars, status bar, etc. must have characteristics. The menu is popped up, and if necessary, it is designed to make a multi-set menu, and the right click should be popped up to implement common operations. The most commonly used operation button is put on the toolbar, and the button is changed if necessary. The status bar shows enough useful information. Message Master In MainFrame, the master of a single document can also be used in the View, all of the pop-up or non-modular dialog boxes of all dialogs are completed in the main control window, and the specific data processing is placed in a separate file. Or is designed to class. Ini read and write, definition and descent, and initial calculations of the global variables, and store exits, etc. in the App class. Ondraw and GDI drawings of each view try to use the memory position diagram to avoid flashing.
Others include ATL, console, embedded program interface, etc., as well as plugins such as IE, such as other containers, etc., such programs may not have to be implemented without MFC, and COM components can be implemented.
6. Troubleshooting and BUG debugging method
Asked hard, good at question. Under the premise of not disturbing the normal work, the developers should help each other, gathering gain, maybe your problem or bug is the foreman of others.
Request from a variety of ways. Professional books, textbooks, journals, electronic documents, and international standards, RFC, etc., Internet, forum, expert group, etc.
The emergence of bugs always has a certain reason, calm look, don't always stand in a small part, change an idea, from another angle, maybe you will make you a dark flower. Use some auxiliary development or debug tools such as Spy , Process Viewer, System Monitor, and more.
Broaden their knowledge. See other programming languages, database knowledge, compilation principles, network protocols, etc., familiar with hardware devices, underlying assembly, digital logic circuits. Use and try other software features and interfaces, have a hundred homes, and make innovative and distinctive functional software.
three. Some habits:
I think a better habit:
1.IF (0 == getDataType (...)) is better than if (getDataType (...) == 0), even if the error will == write =, the compiled layer will be reported.
2.
#define max_downloadnum 20
Struct DownInfo M_DownInfo [MAX_DOWNLOADNUM];
Try not to use the specific size value in the code, define a macro, which is convenient for future maintenance.
3.
Custxg_contable g_lpcustcon [] =
{
{"Numerical strings 1", c_zgb, c_custjbm, c_vt_fbj, "10,000"},
{"Numerical strings 2", c_zsz, c_custjbm, c_vt_fbj, "10,000"},
...
{"Numerical Proportion", C_WTB, C_CustHq, C_VT_FBJ, "%"}
}
INT G_NCUSTNUM = SizeOf (g_lpcustcon) / sizeof (Custxg_Contable);
G_ NCustnum automatically adapts to the size of G_LPCustCon.
4.
The function defines short getinputtype (const char * lpzinput) better than Short GetInputType (Char * lpzinput) so as not to be destroyed in the function body.
5.
The protocol header is defined:
Typedef struct tagdataheadahead
{
Struct {
Unsigned char version: 4;
UNSIGNED Char Headerflag: 2;
UNSIGNED Char Reserved: 2; // Reserved Bits Bits} Info;
Long Nother;
Long reserved; // Reserved 4 bytes
DataHeader;
Define a certain reserved field for expansion of use.
6.
The variable determines that all variables are judged when defining the initial value, or when the class is defined or the program exits.
7.
The coding space must be fully reserved, pay attention to the expandability when encoding.
I think bad habits:
1. The code is " 2", " 4", not " sizeof (short)," sizeof (int) ".
2. FileName [40], not FileName [MAX_PATH].
3. If the GDI resource is used, it does not release, bitmap, brush, etc., it is not SELECT. This will cause the system GDI resource loss or memory disclosure.
4. A large number of non-symbolic variables. The unsigned variable is easy to cause errors, even dead cycles, as little as possible.
5. Using Malloc, Free uses new, delete, and uses Realloc. New, Delete is a standard C syntax, versatility, and Realloc is easily mortgage.
6. #Define Square (x) * (x)
The body should be added parentheses, otherwise it is prone to problems, such as 1 / square (x) will be replaced 1 / (x) * (x)
The above is only some of my summary, less, I hope to throw bricks, please add. (to be continued)
Finish
