+ puts("This string got very far to the "
+ "left and wrapped. ANSI catenation "
+ "rules will turn this into one
+ "long string.");
+@@ -63,7 +80,13 @@ The following lint and lint-like comments should be used where appropriate: .h files should not rely on other files having been included. .h files should prevent multiple inclusion. The OS is assumed to prevent multiple inclusion of its .h files.
-.h files that define modules should have a structure like the following:
+.h files that define modules should have a structure like the
+following. Note that
*****/
/*
- *
+The first file to be included in a C source file must be config.h.
+The config.h file must never be included by any public header file
+(that is, any header file that will be installed by "make install").
+Try to include only necessary files, not everything under the sun.
Operating-system-specific files should not be included by most modules.
Include UNIX "sys" .h files before ordinary C includes.
+There should be at most one statement per line. The comma operator
+should not be used to form compound statements.
Bad:
+
+Generally speaking, when a control statement (
+
Good:
+care what the value is, except for
All error conditions must be handled.
@@ -266,7 +308,13 @@ comparisons between signed and unsigned integers should be avoided;
suppressing the warnings with casts is not desireable.
+Casting should be avoided when possible. When it is necessary, there
+should be no space between the cast and what is being cast.
+
+Bad (obviously for more than one reason ...):
+
+
+Good:
+
+
+Bad:
+
+The {module} and {what} segments of the name do not have underscores
+separating natural word elements, as demonstrated in
+isc_commandline_argument and dns_name_setbuffer above. The {module}
+part is usually the same as the basename of the source file, but
+sometimes other {module} interfaces appear within one file, such as
+dns_label_* interfaces in lib/dns/name.c. However, in the public
+libraries the file name must be the same as some module interface
+provided by the file; e.g., dns_rbt_* interfaces would not be declared
+in a file named redblack.c (in lieu of any other dns_redblack_*
+interfaces in the file).
+
+The one notable exception to this naming rule is the interfaces
+provided by
+
+
-
/*
* Copyright (C) 1998 Internet Software Consortium.
@@ -90,44 +113,48 @@ multiple inclusion of its .h files.C Source
Including Interfaces (.h files)
-The first file to be included must be config.h.
-Try to include only necessary files, not everything under the
-sun.Statements
-There should be at most one statement per line.
if (i > 0) {
printf("yes\n"); i = 0; j = 0;
+ x = 4, y *= 2;
}
Functions
@@ -170,11 +200,20 @@ g(int i, /* other args here */
}
Curly Braces
Curly Braces do not get their own indentation.
+Curly Braces
+Curly Braces do not get their own indentation.
An opening brace does not start a new line. The statements enclosed
by the braces should not be on the same line as the opening or closing
brace. A closing brace should be the only thing on the line, unless
it's part of an else clause.if, for or
+while) has only a single action associated with it, then no
+bracing is used around the statement. Exceptions include when the
+compiler would complain about an ambiguous else clause, or when extra
+bracing improves the readability (a judgement call biased toward not
+having the braces).
+
static void
@@ -200,13 +239,15 @@ void f(int i)
Spaces
-
malloc(4 * sizeof(long)).
Return Values
If a function returns a value, it should be cast to (void) if you don't
-care what the value is. (Exception for printf()?)printfCasting
-Casting should be avoided when possible.
+ (void) malloc(SMBUF);
+Clear Success or Failure
A function should report success or failure, and do so accurately. It
@@ -354,6 +402,88 @@ Bad:
}
The Ternary Operator
+The ?: operator should mostly be avoided. It is tolerated when
+deciding what value to pass as a parameter to a function, such as
+frequently happens with printf, and also when a simple (non-compound)
+value is being used in assignment or as part of a calculation.
+In particular, using the ternary operator to specify a return value is
+verboten.
+
+Bad:
+
+ printf("%c is%s a number.\n", c, isdigit(c) ? "" " NOT");
+ l = (l1 < l2) ? l1 : l2;
+ if (gp.length + (go < 16384 ? 2 : 3) >= name->length) {
+ ...
+ }
+
+
+
+ return (success ? ISC_R_SUCESS : ISC_R_FAILURE);
+Assignment in Parameters
+Variables should not have their values assigned or changed when being
+passed as parameters, except perhaps for the increment and decrement
+operators.
+
+Ok:
+
+ malloc(size = 20);
+
+
+
+ fputc(c++, stdout);
+Namespace
+Public Interfaces
+All public interfaces to functions, macros, typedefs, and
+variables provided by the library, should use names of the form
+{library}_{module}_{what}, such as:
+
+however, structures which are typedef'd generally have the name of the
+typedef sans the final _t:
+
+ isc_buffer_t /* typedef */
+ dns_name_setbuffer(name, buffer) /* function */
+ ISC_LIST_HEAD(list) /* macro */
+ isc_commandline_argument /* variable */
+
+Generally speaking macros are defined with all capital letters, but
+this is not universally consistent (eg, numerous isc_buffer_{foo}
+macros).
+ struct dns_rbtnode {
+ /* ... members ... */
+ }
+Shared Private Interfaces
+When a module provides an interface for internal use by other modules
+in the library, it should use the same naming convention
+described for the public interfaces, except {library} and {module}
+are separated by a double-underscore. This indicates that the name is
+internal, its API is not as formal as the public API, and thus it
+might change without any sort of notice.
+
Initialization
When an object is allocated from the heap, all fields in the object must be
initialized.