房
房客
Unregistered / Unconfirmed
GUEST, unregistred user!
Standard Development Checking List
1. HOW TO START A PROJECT
1.1 Collect related information, i.e. books, software.
1.2 Talk with experts
1.3 Compare the products in the market.
1.4 Decide what feature should be in or not be in, why?
1.5 Setup a small team to start the specification.
1.6 Decide what tools to be used, i.e. compiler, database and other SDK.
1.7 Setup the time line.
1.8 Decide the content at first, then
decide the style.
2. HOW TOdo
A DAY'S JOB
2.1 Write a clear todo
list
2.2 Prioritize the jobs
2.3 At the end of the day, update the readme file
2.3.1 New major functions
2.3.2 Files needed to run the exe
2.4 At the end of the day, integrate your code if there are more than one person in team.
3. HOW TO START A PROJECT IN THE GROUP
3.1 Read the ???readme.doc first to know what work have beendo
ne. See 2.3
4. COMPILATION
The result should be no warning, no error.
5. COMMUNICATIONS
5.1 File name
5.1.1 Style
e.g, jenga_code_sh_d5_97.zip
Where Jenga is the project name, code is the content, sh is the auther, d5_97 is Dec. 5, 97.
5.1.1.1 Note:do
n't use space in the file name. UNIX anddo
s can not handle it.
5.1.2 Why
Maybe you just send a file in week, but other people may get 50 per day. Meaningful file names save us a lot time.
5.2 Email subject
5.2.1 Style
e.g, jenga | code | question
Where Jenga is the project name, code is the content, question is the details.
5.2.2 Why
Maybe you just send a mail in week, but other people may get 50 per day. Meaningful file subjects save us a lot time.
6. DEMO
6.1 Use DemoShield to create a visual demo. For example, MetaStock 6.0 | Visual Tutorial
6.2 Create a limited version for user to try.
6.3 Give user a full version but just valid in 30 days.
7.do
CUMENTATION
7.1 Update check list
7.1.1 Date
7.1.2 Table of content
7.1.3 Index
8. HELP
8.1 Search
A searched word should be highlighted.
8.2 When the menu is pulleddo
wn, right click it to make the help item popped up.
8.3 All help should have an example.
9. INTEGRATE CODE
Use diff.exe, which comes with VC4.x, to compare new dir/file with old ones.
10. KNOWLEDGE BASE (KB)
Every programmer should add his experience into the KB. MS KB is a very good example. The contribution to KB should be a part of the programmer's evaluation.
11. MANUAL
11.1 A quick start tutorial
11.2 Standard manual
12. PROGRAMMING STYLE
12.1 Brackets
Add end mark at the end of each bracket in the content is longer than 20 lines like,
for ( I = 1;
I<100;
I++){
.......
.......
}//End of I loop.
12.2 Bug trapping
12.2.1 All of possible bugs should be trapped to avoid the crashing. Such as
12.2.1.1 Can not open a file or database.
12.2.1.2 Can not locate memory.
12.2.1.3 Add your idea here.
12.2.2 Assertion or Verifying in Debugging mode
12.2.2.1 Value be in a assumed range
12.2.2.2 Pointer not equal NULL
12.2.2.3 Divider not equal zero
12.2.2.4 Add your idea here
12.2.3 Error message
12.2.3.1 Use a common style warning or error message
12.2.3.2 Consider different kinds of possible errors at design step and treat them consistently
12.2.3.3
Error messages should be pop up in the debug version at least.
12.3 Calculation
12.3.1 Reference
All of the calculation must be commented with the source of referecne.
Esp. the meaning of the constants. Otherwise, there is no way for other programmer to figure it out.
12.3.2 Number
12.3.2.1 Style
If you want to write to a line of code like
F_car_speed = f_truck_speed + 2.30f;
You must add comment to tell other why did use + 2.30 here.
12.3.2.2 Why
It maybe a no-brainer job for you to why it is 2.30, but it may other programmer 2 hours to know with your comments.
12.4 File Description
/********************************************************************
* Copyright 1993 3DI Productions
* Description:
* Debugging Tools
* Constains:
* Routines to profile a system.
* written 04/25/93 by Carlos Justiniano
**********************************************************************/
12.5 Function Description
/****************************************************************
* Function name : course_position
* Created by : SH, 96/08/30
* Modified by: SH, 96/09/09
* Purpose: Display the info->course's relative postive to info->sceen
* Parameters: : info: the course info structure
* Return : TRUE for success, FALSE for failure.
*****************************************************************/
BOOL course_position(AppInfo *info){
D3DVECTOR posi,y,z;
info->map->GetPosition(info->scene, &posi);
info->map->GetOrientation(info->camera, &y, &z);
char string[200];
sprintf(string, "Position: %.0f,%.0f,%.0f /n Y axis: %.3f, %.3f, %.3f/n ax ",
float(posi.x), float(posi.y), float(posi.z),
float(y.x), float(y.y), float(y.z),
float(z.x), float(z.y), float(z.z) );
Msg("%s", string);
return TRUE;
}
12.6 Function Length
Try to keep each function less than 100 lines.
12.7 Function return value
If there is no return value necessary,do
n't return void. Use TRUE for success, and FALSE for failure. This will make the debugging work much easier.
12.8 Where to put handler functions
Ref: VC 5.0 | InfoView | Developer Products | Visual C++ toturial | Scribble: MDI Drawing Application | Binding Visual Objects to Code Using WizardBar | Creating Message-Handler Functions with WizardBar | Binding Scribble's Commands | Bind Scribble's Clear All Command to Its Handler Code
In general, put handlers in the command-target class where they have the greatest effect.
When attributes are shared by multiple views or frame windows, put them in the commondo
cument.
If attributes are not shared, put them in the view(s) or window(s) that use them.
12.9 Key word
Write a few key word at the top of file, so code can be reusable in the future projects.
12.10 Variable name
12.10.1 Hungarian Notation
Hungarian Notation is a variable-naming convention, in honor of the legendary Microsoft programmer Charles Simonyi. Very simply, the variable name begin
s with a lowercase letter of letters that denote the data type of the variable. For example, the h prefix in hInstance stands for "handle". The most useful prefixes are in the following table.
Prefix Data Type
c Char
by BYTE (unsigned char)
n Short
I Int
x,y int (used as x- or y-coordinate)
cx,cy int (used as x or y length;
c stands for "count")
b or f BOOL(int), f stands for flag
w WORD (unsigned short)
l LONG (long)
dw DWORD (unsigned long)
fn Function
s String
sz string terminated by 0 byte
h Handle
p Pointer
See Programming Windows 95 by Charles Petzold, P29-30 for details.
12.10.2 Use explaining variable name.do
care even if it is too long.
13. PROBLEM SOLUTIONS
13.1 Principles: No question is too stupid to ask;
no answer is smart to share.
13.2 When you can not think clearly about something, writedo
wn the problem. Divide the problem into a few sub-problem, solve them one by one. It really helps.
13.3 Check help files.
13.4 Checkdo
cumentation.
13.5 Check sample code.
13.6 Ask colleagues.
13.7 Ask friends.
13.8 Post on mailing list.
13.9 Post on news group.
13.10 Search the key word in WWW.
13.11 Avoid the problem by other paths.
13.12 After you solved the problem, write itdo
wn and share with others(Maybe in a problem solution database so that this can be reuse ) .
14. GROUP MEETING
14.1 Extract the code which can be reused, make it as a public interface function, so it will be useful to every body.
14.2 Share everyone's experiences and problems with groupmates
14.3 Meeting regularily
14.4 Keep on well with each other
15. USER INTERFACE
General principles: if there is no obvious logical relationship between menu items, arrange them alphabetically.
15.1 Graphic UI
Use as much icon as possible, but let the user know which is button, which is just pure decoration.do
n't make the users confused.
15.2 For multimedia product
There should be a option to highlight all of the hotspot.
15.3 Right-click
Every item should be right-click-able. When it is right clicked, all of the available operation is shown.
15.4 Drag and drop
Item should be drag-and-drop-able as much as possible.
15.5 Object Orientation
The "object orientation" means that the commands for objects are contained within the objects themselves. Rather than having to search a maze of menus and toolbars, you access commands directly from the objects.
16. QUALITY ASSURANCE
16.1 If there is standard, compare the software with it as much as possible.
16.2 Check whether the implementation is conform to the specification periodically .
16.3 Every modification to the specification should bedo
cumented and widely informed.
17. STATUS REPORT
17.1 What is new from the last week?
17.2 What are the difficulties?
17.3 What is next week plan?
17.4 Due time
The report is due on every Friday (BJ), but I strongly suggest you to send it on Thursday in case of network problem. This is 100% NOT negotiable.
17.5 Time sheet (Not necessary right now)
3.How many hours did you spend on the project in the last 7 days?
Give out details.
18. TEAM:
18.1 Challenge and routines.
Each project can be deviled into tech challenge part and routine part. After tech challenge part is overcome, the team leader should let all of the related persons know. Thus, other guys can just follow the routines.
18.2 Work parallelly.
If there is enough people, devide the project into small pieces. Thus team member can work on it parallely, the project can be finished soon. The cash flow can be controlled easier.
19. TRANSFER A PROJECT
19.1 For VC5.0 project, following files should be mailed
19.1.1 *.dsw
19.1.2 *.dsp
19.1.3 *.c, *.cpp
19.1.4 *.h
19.1.5 resource files
19.1.6 *readme.doc
19.1.7 all of the file required in *readme.doc
19.2 If the project has been mailed before, you may just the mail the changed. Use windiff.exe to compare the difference.
20. HOW TO CLOSE A PROJECT
20.1 Remove the unnecessary code.
20.2 Add all necessary comment
20.3 Finish necessarydo
cumentation
20.4 Make sure the exe is a release version instead of debug version.
20.5 Create a installation version with Install Shield.
20.6 Check this check list.
21. ANY COMMENTS ON THISdo
CU IS WELCOMED AND APPRICIATED.
1. HOW TO START A PROJECT
1.1 Collect related information, i.e. books, software.
1.2 Talk with experts
1.3 Compare the products in the market.
1.4 Decide what feature should be in or not be in, why?
1.5 Setup a small team to start the specification.
1.6 Decide what tools to be used, i.e. compiler, database and other SDK.
1.7 Setup the time line.
1.8 Decide the content at first, then
decide the style.
2. HOW TOdo
A DAY'S JOB
2.1 Write a clear todo
list
2.2 Prioritize the jobs
2.3 At the end of the day, update the readme file
2.3.1 New major functions
2.3.2 Files needed to run the exe
2.4 At the end of the day, integrate your code if there are more than one person in team.
3. HOW TO START A PROJECT IN THE GROUP
3.1 Read the ???readme.doc first to know what work have beendo
ne. See 2.3
4. COMPILATION
The result should be no warning, no error.
5. COMMUNICATIONS
5.1 File name
5.1.1 Style
e.g, jenga_code_sh_d5_97.zip
Where Jenga is the project name, code is the content, sh is the auther, d5_97 is Dec. 5, 97.
5.1.1.1 Note:do
n't use space in the file name. UNIX anddo
s can not handle it.
5.1.2 Why
Maybe you just send a file in week, but other people may get 50 per day. Meaningful file names save us a lot time.
5.2 Email subject
5.2.1 Style
e.g, jenga | code | question
Where Jenga is the project name, code is the content, question is the details.
5.2.2 Why
Maybe you just send a mail in week, but other people may get 50 per day. Meaningful file subjects save us a lot time.
6. DEMO
6.1 Use DemoShield to create a visual demo. For example, MetaStock 6.0 | Visual Tutorial
6.2 Create a limited version for user to try.
6.3 Give user a full version but just valid in 30 days.
7.do
CUMENTATION
7.1 Update check list
7.1.1 Date
7.1.2 Table of content
7.1.3 Index
8. HELP
8.1 Search
A searched word should be highlighted.
8.2 When the menu is pulleddo
wn, right click it to make the help item popped up.
8.3 All help should have an example.
9. INTEGRATE CODE
Use diff.exe, which comes with VC4.x, to compare new dir/file with old ones.
10. KNOWLEDGE BASE (KB)
Every programmer should add his experience into the KB. MS KB is a very good example. The contribution to KB should be a part of the programmer's evaluation.
11. MANUAL
11.1 A quick start tutorial
11.2 Standard manual
12. PROGRAMMING STYLE
12.1 Brackets
Add end mark at the end of each bracket in the content is longer than 20 lines like,
for ( I = 1;
I<100;
I++){
.......
.......
}//End of I loop.
12.2 Bug trapping
12.2.1 All of possible bugs should be trapped to avoid the crashing. Such as
12.2.1.1 Can not open a file or database.
12.2.1.2 Can not locate memory.
12.2.1.3 Add your idea here.
12.2.2 Assertion or Verifying in Debugging mode
12.2.2.1 Value be in a assumed range
12.2.2.2 Pointer not equal NULL
12.2.2.3 Divider not equal zero
12.2.2.4 Add your idea here
12.2.3 Error message
12.2.3.1 Use a common style warning or error message
12.2.3.2 Consider different kinds of possible errors at design step and treat them consistently
12.2.3.3
Error messages should be pop up in the debug version at least.
12.3 Calculation
12.3.1 Reference
All of the calculation must be commented with the source of referecne.
Esp. the meaning of the constants. Otherwise, there is no way for other programmer to figure it out.
12.3.2 Number
12.3.2.1 Style
If you want to write to a line of code like
F_car_speed = f_truck_speed + 2.30f;
You must add comment to tell other why did use + 2.30 here.
12.3.2.2 Why
It maybe a no-brainer job for you to why it is 2.30, but it may other programmer 2 hours to know with your comments.
12.4 File Description
/********************************************************************
* Copyright 1993 3DI Productions
* Description:
* Debugging Tools
* Constains:
* Routines to profile a system.
* written 04/25/93 by Carlos Justiniano
**********************************************************************/
12.5 Function Description
/****************************************************************
* Function name : course_position
* Created by : SH, 96/08/30
* Modified by: SH, 96/09/09
* Purpose: Display the info->course's relative postive to info->sceen
* Parameters: : info: the course info structure
* Return : TRUE for success, FALSE for failure.
*****************************************************************/
BOOL course_position(AppInfo *info){
D3DVECTOR posi,y,z;
info->map->GetPosition(info->scene, &posi);
info->map->GetOrientation(info->camera, &y, &z);
char string[200];
sprintf(string, "Position: %.0f,%.0f,%.0f /n Y axis: %.3f, %.3f, %.3f/n ax ",
float(posi.x), float(posi.y), float(posi.z),
float(y.x), float(y.y), float(y.z),
float(z.x), float(z.y), float(z.z) );
Msg("%s", string);
return TRUE;
}
12.6 Function Length
Try to keep each function less than 100 lines.
12.7 Function return value
If there is no return value necessary,do
n't return void. Use TRUE for success, and FALSE for failure. This will make the debugging work much easier.
12.8 Where to put handler functions
Ref: VC 5.0 | InfoView | Developer Products | Visual C++ toturial | Scribble: MDI Drawing Application | Binding Visual Objects to Code Using WizardBar | Creating Message-Handler Functions with WizardBar | Binding Scribble's Commands | Bind Scribble's Clear All Command to Its Handler Code
In general, put handlers in the command-target class where they have the greatest effect.
When attributes are shared by multiple views or frame windows, put them in the commondo
cument.
If attributes are not shared, put them in the view(s) or window(s) that use them.
12.9 Key word
Write a few key word at the top of file, so code can be reusable in the future projects.
12.10 Variable name
12.10.1 Hungarian Notation
Hungarian Notation is a variable-naming convention, in honor of the legendary Microsoft programmer Charles Simonyi. Very simply, the variable name begin
s with a lowercase letter of letters that denote the data type of the variable. For example, the h prefix in hInstance stands for "handle". The most useful prefixes are in the following table.
Prefix Data Type
c Char
by BYTE (unsigned char)
n Short
I Int
x,y int (used as x- or y-coordinate)
cx,cy int (used as x or y length;
c stands for "count")
b or f BOOL(int), f stands for flag
w WORD (unsigned short)
l LONG (long)
dw DWORD (unsigned long)
fn Function
s String
sz string terminated by 0 byte
h Handle
p Pointer
See Programming Windows 95 by Charles Petzold, P29-30 for details.
12.10.2 Use explaining variable name.do
care even if it is too long.
13. PROBLEM SOLUTIONS
13.1 Principles: No question is too stupid to ask;
no answer is smart to share.
13.2 When you can not think clearly about something, writedo
wn the problem. Divide the problem into a few sub-problem, solve them one by one. It really helps.
13.3 Check help files.
13.4 Checkdo
cumentation.
13.5 Check sample code.
13.6 Ask colleagues.
13.7 Ask friends.
13.8 Post on mailing list.
13.9 Post on news group.
13.10 Search the key word in WWW.
13.11 Avoid the problem by other paths.
13.12 After you solved the problem, write itdo
wn and share with others(Maybe in a problem solution database so that this can be reuse ) .
14. GROUP MEETING
14.1 Extract the code which can be reused, make it as a public interface function, so it will be useful to every body.
14.2 Share everyone's experiences and problems with groupmates
14.3 Meeting regularily
14.4 Keep on well with each other
15. USER INTERFACE
General principles: if there is no obvious logical relationship between menu items, arrange them alphabetically.
15.1 Graphic UI
Use as much icon as possible, but let the user know which is button, which is just pure decoration.do
n't make the users confused.
15.2 For multimedia product
There should be a option to highlight all of the hotspot.
15.3 Right-click
Every item should be right-click-able. When it is right clicked, all of the available operation is shown.
15.4 Drag and drop
Item should be drag-and-drop-able as much as possible.
15.5 Object Orientation
The "object orientation" means that the commands for objects are contained within the objects themselves. Rather than having to search a maze of menus and toolbars, you access commands directly from the objects.
16. QUALITY ASSURANCE
16.1 If there is standard, compare the software with it as much as possible.
16.2 Check whether the implementation is conform to the specification periodically .
16.3 Every modification to the specification should bedo
cumented and widely informed.
17. STATUS REPORT
17.1 What is new from the last week?
17.2 What are the difficulties?
17.3 What is next week plan?
17.4 Due time
The report is due on every Friday (BJ), but I strongly suggest you to send it on Thursday in case of network problem. This is 100% NOT negotiable.
17.5 Time sheet (Not necessary right now)
3.How many hours did you spend on the project in the last 7 days?
Give out details.
18. TEAM:
18.1 Challenge and routines.
Each project can be deviled into tech challenge part and routine part. After tech challenge part is overcome, the team leader should let all of the related persons know. Thus, other guys can just follow the routines.
18.2 Work parallelly.
If there is enough people, devide the project into small pieces. Thus team member can work on it parallely, the project can be finished soon. The cash flow can be controlled easier.
19. TRANSFER A PROJECT
19.1 For VC5.0 project, following files should be mailed
19.1.1 *.dsw
19.1.2 *.dsp
19.1.3 *.c, *.cpp
19.1.4 *.h
19.1.5 resource files
19.1.6 *readme.doc
19.1.7 all of the file required in *readme.doc
19.2 If the project has been mailed before, you may just the mail the changed. Use windiff.exe to compare the difference.
20. HOW TO CLOSE A PROJECT
20.1 Remove the unnecessary code.
20.2 Add all necessary comment
20.3 Finish necessarydo
cumentation
20.4 Make sure the exe is a release version instead of debug version.
20.5 Create a installation version with Install Shield.
20.6 Check this check list.
21. ANY COMMENTS ON THISdo
CU IS WELCOMED AND APPRICIATED.