My programmer code
Author: Fox
time:
2003-12-9
Version: First Draft
1 General
This article describes some of the experience crosses that the author exploited from the practice of software development.
Through the comparison of these guidelines, I can often make my own daily behaviors from my daily behavior in software development, to achieve the purpose of improving software quality and writing software efficiency.
This article is the first draft, and the new idea will be supplemented or modified for the existing shortcomings.
This article hopes to help the programmer colleagues.
2 rule
2.1 Code Specification
The readability of software code is important for maintenance of software collaborative development and release, and the "beautifulness" of the code also reflects a programmer's coding level.
2.1.1 Naming Rules
Names include class name, function name, variable name, etc.
Name Don't use the name of the name and Chinese. Naming to reflect the meaning of the corresponding variable or function.
Naming rules mainly include Hungarian nomenclature and UNIX / Java nomenclature (I can't remember the specific name :), the former is often used in the Windows program code, while the latter is in a standard C program or Java program.
The disadvantage of the former is that naming is not very clear, the case is mixed together; the advantage is that the meaning is very clear, and even a variable can be seen from the name.
Please refer to the appendix for the rules details of Hungarian naming.
2.1.2 Code Indentation
The code is to be aligned, and the level is clear. This is an important factor in determining the clearness of the code.
Modern dedicated editor has good intelligence processing on code's typography, such as MS VC is a very good choice, and its default typography can guarantee automatic indentation of the code.
The width of the Tab is set to 4 spaces, but still keeps Tab characters, do not replace them with spaces.
Tips: If your code has become very bad due to some reason, you don't have to worry. You can select the code you want to format in the VC editor, then press Alt F8.
2.1.3 Notes
Note Generally there are two ways: conventional annotation methods in C language (/ * Note * /) and C annotation methods (// Note).
The former is suitable for large block code notes, while the latter is suitable for a single line of comments.
The biggest shortcomings in the former are not to support nested annotations, otherwise compile errors will be generated; and the latter needs each line to add "//" for large blocks, slightly troublesome. However, the version of VC7 has supported a comment for "//" simultaneously on multi-line code, or using Visual Assist.
Note According to the position, it can be divided into code within the code and document comments. There is no requirement within the code, but to indicate a piece of function, the difficulty of certain details, and the code itself can be obviously expressed. Document comments mainly include developing documents and description documents for interfaces.
2.1.4 Code Distribution
One module (with C as an example, part of the {}) should not exceed 50 rows; one function should not exceed 100 rows; one source file is preferably not more than 1000, up to 5000 rows.
A relatively independent project should have a work space (VC6 as a .dsw file) or solution (for a.sln file in VC7), which can contain multiple projects (.prj, .dsp or .vcproj). One .h and .cpp include a class that is very close to the relationship, or a class is only used for another class, or it can be placed in a source file.
For OOP unless it is no longer, there is no global variable and global function, this is the basic requirements of OOP.
2.2 Document Specification
Documentation should join CVS and order a directory. Including design documents, development documents, user manuals, etc. An additional specification document can also be used as a directory as a guidelines for programmers, such as this article. Demand and design documentation and specifications for documentation, that is, not only to use documents to end users.
If you write a program under Windows, the document is unified using the Word .DOC format. Note that adding CVS to use a binary format.
Document Naming Rules: "Date _ Title _ Author_St.doc", such as "031209_ programmer code _fox_1_0.doc", but adding CVS documents should remove the date and version, ie "title _ author .doc", Such as "programmer code _fox.doc", because CVS itself records the date and version.
2.3 Code Management / Version Control
2.3.1 Management Tools
The code management tools are mainly MS Visual SourceSafe and CVS (WinCVS). Recommended use latter.
2.3.2 Precautions
Update (UPDATE) CVS before working every day, submits CVS when you get off, submit (Commit), and reduce the possibility of conflict. The submission of the code must be compiled. Every time you submit, you will see the reason for the revision of the comment bar, for future views and other programmers.
No need to add CVS files: You can compile the generated files generated by code in CVS, and the integrated environment is based on files generated by user preferences. However, the .lib or .dll file provided by a third party should be added to CVS. In short, to ensure the integrity of the code, do "not heavy".
2.3.3 Directory layers
Directory hierarchy: Press the project to block, then press the H, LIB, SOURCE directory structure.
2.3.4 Version Management
Every time a Release version, you must hit the tag in CVS so that you can re-take it at any time.
The use and maintenance of the public library.
2.3.5 Using Nightly Build
Nightly Build technology and CVS combine can automatically complete a version of the acquisition, compile, link, and testing a whole process. Especially for large-scale projects above hundreds of thousands of lines, artificial intervention is very cumbersome and easy to make mistakes, using Nightly Build to help us solve this problem.
2.4 BUG tracking
BUG Track is an important part of the software development process, and the Software test engineer is required to test software that has been basically completed.
BUG tracks There are many free tools to download online, mostly web-based, convenient for many people to participate.
BUG tracking process: Test personnel discovered and submit bugà software engineers to repair and / or feedback Bugà tester confirmed that bug has been repaired à admin to freeze or end confirmed bugs.
2.5 Software Engineering / Project Design
Several links of software engineering: plan, coding, testing, maintenance, etc.
2.5.1 Program
There must be a careful plan before each project started, and the software engineering is no exception. The plan is mainly divided into stages of demand analysis, functional design, workload estimation, time schedule and module division.
Software plan is a key part of software engineering. "Good start is half of success", good demand analysis, progress arrangement is an important factor in successful overall project.
Plan for 1/3 of the entire software engineering cycle.
2.5.2 encoding
(For details, please see the section above.)
Purely coding is not much time, accounting for 1/6 of the entire software engineering cycle.
2.5.3 Test
Tests can be divided into unit testing and integration tests according to the scope; in the nature divided into white box testing and black box test.
Unit test is important, can not be ignored, often some issues found or difficult to find the problem in the integrated test phase or difficult to find the problem is not good. The integrated test is to test the entire system integrated into each module, mainly test system functions and performance. The white box test is mainly tested within the programmer, possessed the source code, and some modifications can be modified to better discover BUG and locating causing bug code. Black box testing can be made by testers or even end users to establish a dedicated website (BUG tracking system) feedback.
Testing 1/4 of the entire software engineering cycle.
Tips:
The test product should use the Debug version, because the debug version contains debugging information, it can be convenient for BUG positioning.
Appropriate use of Assert, check parameters, or conditions in your code, you can discover some bugs, reducing a part of the test.
2.5.4 Maintenance
Maintenance is indeed a very difficult thing. Bug fixes found in the test phase, the user's change of the needs, etc., will be a longer time, in fact maintenance of 1/4 of the entire software cycle. At this time, the extent of software maintenance, the cost is high, and it is largely reflected the quality of the pre-design requirements analysis and the quality of the coding quality, the advantages and disadvantages of software telescopic performance.
2.6 team building
A good product needs a good team, a good team needs a good team building. A good team building can make people feel enthusiastically, stimulate the enthusiasm and creativity of team members.
Team construction mainly includes: the selection of personnel, training, task allocation, and collective activities of spare time. It is very important to reflect the mutual concern between the work and the group members, you can give the team a warm, comfortable, relaxed environment.
2.7 Environmental configuration
The company or studio sets a domain, where each computer is joined in this domain, unified management. Each project group is a group in the domain, and the project team member is the user in the domain group. Each group member assigns a fixed computer.
The domain name can be made into the company's name. Each computer assigns a computer name corresponding to a network IP and a group member to make it easy for other users to find. Also configure a computer that can be directly connected to the Internet, and other computers are online. This proxy server is best to separate the domain controller.
In addition, there is a computer that stores shared data, such as common tools, data backups, and more. As for security issues such as user authentication, we can solve them by configuring the domain.
3 appendix
3.1 Naming Rules - Hungarian Name Method
3.2 WinCVS User Manual and CVS Command Speed Check Manual
3.3 BUG Tracking System Introduction
3.4 Example of Excellent Code
3.5 Example of Excellent Document
