Best practices for programming in C
Shiv Dutta, Technical Consultant, IBM, Software Group
Gary Hook(ghook@us.ibm), Senior Technical Consultant, IBM, Software Group
Summary: Although the C language has been around for close to 30 years, its appeal has not yet worn off. It continues to attract a large number of people who must develop new skills for writing new applications, or for porting or maintaining existing applications.
Introduction
This article has been written with the needs of the developer in mind. We have put together a set of guidelines that have served us well as developers and consultants over the years, and we offer these as suggestions that may help you in your job. You may not agree with all of them but our hope is you would like some of them and use them in your programming or porting projects.
Back to top
•Use a source code style that makes the code readable and consistent.
Unless you have a group code style or a style of your own, you could use a style similar to the Kernighan and Ritchie style used by a vast majority of C programmers. Taken to an extreme, however, it's possible to end up with something like this:
int
i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\
o,
world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);
•
•--Dishonorable mention, Obfuscated C Code Contest, 1984. Author requested anonymity.
•It is common to see the main routine defined as main(). The ANSI way of writing this is int main(void) (if there are is no interest in the command line arguments) or as int main( int argc, char
**argv ). Pre-ANSI compilers would omit the void declaration, or list the variable names and follow with their declarations. •Whitespace
Use vertical and horizontal whitespace generously. Indentation and spacing should reflect the block structure of the code.
A long string of conditional operators should be split onto separate
lines. For example:
if (foo->next==NULL && number < limit && limit <=SIZE
&& node_active(this_input)) {...
might be better as:
if (foo->next == NULL
中秋祝福语 送客户&& number < limit && limit <= SIZE
&& node_active(this_input))
{
...
Similarly, elaborate for loops should be split onto different lines:
for (curr = *varp, trail = varp;
curr != NULL;
trail = &(curr->next), curr = curr->next )
{
...
Other complex expressions, such as those using the ternary ?: operator, are best split on to several lines, too.
z = (x == y)
? n + f(x)
: f(y) - n;
•Comments
The comments should describe what is happening, how it is being done, what parameters mean, which globals are used and any restrictions or bugs. However, avoid unnecessary comments. If the code is clear, and uses good variable names, it should be able to explain itself well. Since comments are not checked by the compiler, there is no guarantee they are right. Comments that disagree with the code are of negative value. Too many comments clutter code.
Here is a superfluous comment style:
i=i+1; /* Add one to i */
It's pretty clear that the variable i is being incremented by one.
And there are worse ways to do it:
/************************************
* *
抖音忠哥车祸死了* Add one to i *
* *
************************************/ i=i+1;
•Naming Conventions
Names with leading and trailing underscores are reserved for system purposes and should not be used for any user-created names.
Convention dictates that:
1.#define constants should be in all CAPS.
3.Function, typedef, and variable names, as well as struct,
union, and enum tag names should be in lower case.
For clarity, avoid names that differ only in case, like foo and Foo .
Similarly, avoid foobar and foo_bar. Avoid names that look like each other. On many terminals and printers, 'l', '1' and 'I' look quite
similar. A variable named 'l' is particularly bad because it looks so much like the constant '1'.
•Variable names
When choosing a variable name, length is not important but clarity of expression is. A long name can be used for a global variable which is rarely used but an array index used on every line of a loop need not be named any more elaborately than i. Using 'index' or
'elementnumber' instead is not only more to type but also can obscure the details of the computation. With long variable names sometimes it is harder to see what is going on. Consider:
for(i=0 to 100)
array[i]=0
versus
for(elementnumber=0 to 100)
array[elementnumber]=0;
•Function names
Function names should reflect what they do and what they return.
Functions are used in expressions, often in an if clause, so they need to read appropriately. For example:
if (checksize(x))
is unhelpful because it does not tell us whether checksize returns true on error or non-error; instead:
if (validsize(x))
开学第一课的读后感怎么写makes the point clear.
•Declarations
All external data declaration should be preceded by the extern keyword.
The "pointer'' qualifier, '*', should be with the variable name rather than with the type.
char *s, *t, *u;
instead of荷花的描写优美句子
char* s, t, u;
梁静茹前夫发文The latter statement is not wrong, but is probably not what is desired since 't' and 'u' do not get declared as pointers.
•Header Files
Header files should be functionally organized, that is,
declarations for separate subsystems should be in separate header files. Also, declarations that are likely to change when code is ported from one platform to another should be in a separate header file.
Avoid private header filenames that are the same as library header filenames. The statement #include "math.h'' includes the standard library math header file if the intended one is not found in the current directory. If this is what you want to happen, comment this fact.
Finally, using absolute pathnames for header files is not a good idea. The "include-path'' option of the C compiler (-I (capital "eye") on many systems) is the preferred method for handling extensive private libraries of header files; it permits
reorganizing the directory structure without having to alter source files.
发布评论