1, copyright and version ------ good programmer will give each function, each file, and pay on copyright and version.
For C / C files, the file head should have a comment like this: / ******************************** **************************************** File name: network name: network.c ** file Description: Network Communication Function Set ** Creation: Hao Chen, February 3, 2003 ** Version Number: 1.0 ** Modify Record: ****************** *********************************************************** **** /
For functions, there should also be similar to this note:
/ * ================================================================================================================================================================ ================== * * Function name: xxx * * parameter: * * Type name [in]: descripts * * Function Description: * * ....... ....... * * Return Value: Success True, failed false * * throw exception: * * Servers: chenhao 2003/4/2 * =============== ========================================================= * /
Such a description can make people have a function, one file has a general understanding, which has a great advantage for the easy-to-readability and easy maintenance of the code. This is a good start.
2, indent, space, wrap, blank line, alignment -------------- i) indentation should be done every program, as long as the program is programs, you should know This, but I still have seen the procedure that does not indent, or the procedure that is indent, if your company also has a programmer who writes the program, please open him without hesitation, and destroys the sin of the source Prosecution of him, but he still compensates that the mental loss fees for those who have read his procedures. Indent, this is an incumbent rule, and I will retrieve it, a indentation is generally a Tab key or 4 spaces. (It is best to use 4 spaces) <- by netizen vector_3d reminder correction
II) space. Does the space will give the program? No, effective use of spaces can make your program read more and pleasing. Not a pile of expressions are squeezed together. Take a look at the code below:
HA = (HA * 128 * Key )% tabptr-> size; ha = (ha * 128 * key )% tabptr-> size;
It feels different from space and no space. In general, the statement is equipped between the individual operations, and when the function is called, it is equipped with each parameter. Such a split and non-added: IF ((HPROC = OpenProcess, false, pid) == null) {}
IF ((HPROC = OpenProcess, false, pid) == null) {}
Iii) Retained. Don't write the statement on a line, this is very bad. Such as:
For (i = 0; i
How much? Sometimes, when the function parameters are more, it is best to go, such as:
CreateProcess (NULL, CMDBUF, NULL, NULL, BINHH, DWCRTFLAGS, ENVBUF, NULL, & SistartInfo, & Prinfo);
Conditional statements should also be wrapped when necessary: if (CH> = '0' || CH <= '9' || CH> = 'A' || CH <= 'Z' || CH> = 'A' | | CH <= 'Z')
IV) blank line. Don't spoil, the blank line can distinguish between different blocks, blocks, and best to add space lines. Such as:
Handle HProcess; Process_t procinfo;
/ * Open the process Handle * / IF (HProcess = OpenProcess, false, pid) == null) {RETURN LSE_MISC_SYS;}
MEMSET (& Procinfo); procinfo.idproc = pid; procinfo.hdproc = hprocess; procinfo.misc | = mscava_proc; return (0); v) alignment. Use the Tab keys to the declaration or comment of your variables, you will make your program look good. Such as:
typedef struct _pt_man_t_ {int numProc; / * Number of processes * / int maxProc; / * Max Number of processes * / int numEvnt; / * Number of events * / int maxEvnt; / * Max Number of events * / HANDLE * pHndEvnt; / * Array Of Events * / DWORD TIMEOUT; / * TIME OUT Interval * / Handle Hpipe; / * namedpipe * / tchar USR [MAXUSR]; / * user name of the process * / int Nummsg; / * Number of message * / INT MSG [MAXMSG]; / * Space for Intro Process Communicate * /} PT_MAN_T;
how about it? It feels good.
Here mainly tells the story, if you write a pleasing code, the good-looking code will make people feel happy, read the code, not tired, work, neat program code, usually more welcome, more people. Now the hard disk space is so big, don't let your code squeeze together so they will complain that you abuse them. Ok, use "indentation, space, wrap, blank, align" to decorate your code, let them get a row of ordinary organs from there is no order.
3, program comments ------ Develop the habit of writing the program annotation, this is the work that each programmer must do. I have seen that thousands of lines, but there is no row of comments. This is like driving on the road, but there is no road sign. How long does it take? I don't know my intention, I have to spend a few times, I understand that this kind of people who waste others and their own time are the most compussia.
Yes, you may say, you will write a comment, really? The writing of the comment can also see a programmer's skill. Generally speaking, you need to write a note at least in these places: The annotation of the file, the comment of the function, the comment of the variable, the comment of the algorithm, the program comment of the function block. Mainly to record what is your program? What is your intent? What is your variable used? and many more.
Don't think about it, there are some algorithms that it is difficult or written. It can only be aimed. I admit that there is this situation, but you have to write it, just can train your own expression. The ability to express the technicians of the kind of technicians who are stuffy, you have a high technology, if you express your ability, your technology will not be able to get full. Because this is a team's era.
Ok, say the technical details of several comments: i) I don't agree with the row bet ("//") than the block annotation ("/ * * /"). Because some old versions of the C compiler do not support row notes, for your program's portability, please try to use block comments.
II) You may not be nested by the block annotation, then you can use the precompilation to complete this feature. Use the code enclosed in "#IF 0" and "#ndif", will not be compiled, and it can be nested.
4, function [in] [out] parameter -----------
I often see such procedures: funcname (char * str) {int Len = strlen (str); .....}
Char * getUsername (Struct User * Puse) {Return PUSER-> Name;}
Do not! Please don't do this.
You should first judge that the pointer to come in is empty. If the pointer passed is empty, then a big system will crash because of this small function. A better technology is to use assertions (Assert), here I don't have much to say these technical details. Of course, if it is in C , reference is much better than the pointer, but you also need to check each parameter.
When writing a function of parameters, the primary work is to perform all the parameters that come in and perform legality checks. The parameters of the outgoing parameters should also be checked. This action should of course be external to the function, that is, after the call is completed, the value it will be checked.
Of course, check will be wasted, but for the entire system, "illegal operation" or "Core Dump" error, how many spends this time is still worth it.
5, the return to the system call to determine -------------- Continue the previous one, for some system calls, such as opening the file, I often see that many programmers return to FOPEN not Do any judgment, use it directly. Then find that the content of the file is not read, or you can't write it. Still judge:
FP = fopen ("log.txt", "a"); if (fp == null) {printf ("error: Open file error / n"); Return False;
There are still many other, such as: Socket number returned by Socket, Malloc returned by Mall. Please judge what these system calls returned.
<- Previous Next->
(All rights reserved, please indicate the source and author information when reproduced)
