docs/tech/d.html

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Style-Type" content="text/css"/>
<style type="text/css">@import "style.css";</style>
<title>IRC Services Technical Reference Manual - Appendix D. Coding style guidelines</title>
</head>

<body>
<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>

<h2 class="section-title">Appendix D. Coding style guidelines</h2>

<p class="section-toc">
     D-1. <a href="#s1">Formatting</a>
<br/>D-2. <a href="#s2">Identifier naming</a>
</p>

<p class="backlink"><a href="index.html">Table of Contents</a></p>

<!------------------------------------------------------------------------>
<hr/>

<p>The following guidelines were observed when writing the Services source
code.  Note, however, that they were treated as guidelines, not rules, with
the cardinal rule being "readability first".</p>

<!------------------------------------------------------------------------>
<hr/>

<h3 class="subsection-title" id="s1">D-1. Formatting</h3>

<ul>
<li class="spaced">Lines must not be longer than 79 columns.</li>

<li class="spaced">The basic indentation unit is four columns.</li>

<li class="spaced">Tab (ASCII <tt>\011</tt>) characters are not permitted
        in source files; indents should always be done using using spaces
        (<tt>\040</tt>).  The source files distributed with Services
        include settings for the Emacs and Vim editors that cause the Tab
        key to insert spaces rather than a tab character.</li>

<li class="spaced">Only one statement is allowed per line.  Statements
        (including the empty statement "<tt>;</tt>") may not be written on
        the same line as a control keyword (<tt>if</tt>, <tt>for</tt>, or
        <tt>while</tt>).</li>

<li class="spaced">Spaces are placed between binary operators and their
        operands, except for the member-reference operators "<tt>-&gt;</tt>"
        and "<tt>.</tt>"; spaces are not placed between unary operators and
        their operands.  However, spaces may be omitted around binary
        operators when it would improve readability.  Examples:

        <div class="code">i = j * 2;
user-&gt;channelcount++;
result += i*60 + (j+59)/60;</div></li>

<li class="spaced"><tt>NULL</tt>, not <tt>0</tt>, should always be used in
        pointer comparisons.  For character comparisons, <tt>0</tt> is
        preferred to <tt>'\0'</tt>, but the latter may also be used if it
        does not go against the style of the surrounding code.  Do not use
        <tt>'\0'</tt> with variables declared as type <tt>int8</tt> or
        <tt>uint8</tt>, even though these types are usually equivalent to
        <tt>char</tt> and <tt>unsigned char</tt>.</li>

<li class="spaced">The construct "<tt>!!<i>expression</i></tt>" should not
        be used.  Use "<tt><i>expression</i> != 0</tt>" (for characters or
        integers) or "<tt><i>expression</i> != NULL</tt>" (for pointers)
        instead.</li>

<li class="spaced">Parentheses are required when <tt>&&</tt> and
        <tt>||</tt> are used in the same expression to explicitly indicate
        order of evaluation; do not rely on the default order of evaluation.
        (Not using parentheses will generate a warning when using <tt>gcc
        -Wall</tt>.)</li>

<li class="spaced">Parentheses following the control statements "<tt>if</tt>",
        "<tt>for</tt>", and "<tt>while</tt>", as well as the macros
        <tt>LIST_FOREACH</tt>, <tt>LIST_FOREACH_SAFE</tt>, and
        <tt>ARRAY_FOREACH</tt>, are preceded by a space.  Parentheses
        following function or macro calls (other than the above) are not
        preceded by a space.  Example:

        <div class="code">if (flag)
    function();</div></li>

<li class="spaced">Spaces are placed after the comma of each parameter to a
        function or macro; however, they may be omitted in function calls
        which are themselves parameters to a function or macro, or when
        including them would make the line exceed the length limit.  Spaces
        are also placed after (but not before) the semicolons in a
        <tt>for</tt> statement.  Spaces are not placed after the opening
        parenthesis or before the closing parenthesis of a function/macro
        call or control statement.  Examples:

        <div class="code">function(param1, param2);
function(param1, strchr(string,'/'), param3);
for (i = 0; i < count; i++) ...</div></li>

<li class="spaced">Opening braces of control statement blocks go on the
        same line as the control statement (<tt>if</tt>, <tt>for</tt>,
        etc.) associated with the block; function blocks and "naked blocks"
        (those not associated with any control statement or function) have
        the opening brace alone on a line, indented to the same level as
        the surrounding code.  Closing braces are indented to the same
        level as the line containing the opening brace.  Examples:

        <div class="code">if (flag) {
    /* indented code goes here */
    ...
}

int function(int param1, char *param2)
{
    /* indented code goes here */
    ...
    /* start of a naked block */
    {
        int foo;
        ...
    }
}</div></li>

<li class="spaced">If an <tt>if</tt> statement is longer than one line, it
        should be broken at logical operators (<tt>&&</tt> or <tt>||</tt>);
        the operator should be placed at the beginning of the next line,
        and should be indented to show which term the operator belongs
        with.  The closing parenthesis for the <tt>if</tt> statement and
        the subsequent open brace should be alone on a line, aligned with
        the first line of the <tt>if</tt> statement.  (Braces are required
        in this case.)  Conditions for <tt>for</tt> and <tt>while</tt>
        statements should never span multiple lines, though a <tt>for</tt>
        statement may be broken at the semicolons if necessary.  Examples:

        <div class="code">if (ok && (strcmp(option, "option-name-1") == 0
           || strcmp(option, "option-name-2") == 0)
) {
    ...
}

if (!init_first()
 || !init_second()
 || !init_third()
 || !init_fourth()
) {
    /* This example outdents the || by three spaces to line
     * up the terms.  Such outdenting is acceptable if it
     * makes the code easier to read and understand. */
    ...
}

for (exception = first_maskdata(MD_EXCEPTION); exception != NULL;
     exception = next_maskdata(MD_EXCEPTION)
) {
    ...
}</div></li>

<li class="spaced">An <tt>else</tt> followed by an <tt>if</tt> is considered to be a
        single keyword, "<tt>else if</tt>".  The <tt>if</tt> part should
        always be placed on the same line as and immediately following the
        <tt>else</tt>; the <tt>else if</tt> should never be split up onto
        two lines, nor should braces be used around the <tt>if</tt> block.
        The exception to this is when the <tt>else</tt> and <tt>if</tt>
        refer to two conceptually distinct sets of conditions, in which
        case the <tt>if</tt> block should be enclosed by braces and
        indented.  Example:

        <div class="code">res = check_password( /* ... */ );
if (res == 0) {
    ...
} else if (res == 1) {
    /* "else if" on a single line */
    ...
} else {
    if (user-&gt;ni != NULL) {
        /* "if" condition is different from "else"
         * condition, thus separate */
        ...
    }
}</div></li>

<li class="spaced">Braces are always placed around the body of a control statement
        (<tt>if</tt>, <tt>for</tt>, etc.).  The two exceptions are
        <tt>else</tt> followed by <tt>if</tt>, mentioned above, and
        statements for which the body, as well as the bodies of any
        <tt>else if</tt> or <tt>else</tt> statements for an <tt>if</tt>
        statement, are all one statement in length and do not contain any
        nested control statements; in this latter case, braces are optional
        (but recommended if any of the statements span multiple lines).
        Examples:

        <div class="code">for (i = 0; i < count; i++)
    function(i);

while (!done) {
    /* Braces required because of the nested "if" */
    if (do_stuff())
        done = 1;
}

if (state == 0) {
    a = b;
} else if (state == 1) {
    /* Every if/else body gets braces because this body
     * has two statements */
    b += a;
    a = 0;
} else {
    state = 0;
}</div></li>

<li class="spaced">When using multiply-nested control statements, or a single control
        statement which has a long block, the closing brace of the block
        should be followed by a comment indicating what control statement
        the block belongs to.  This should usually be the content of the
        control statement, but may be abbreviated as long as its meaning is
        clear.  If a long <tt>if</tt> block is followed by an <tt>else</tt>
        clause, the <tt>else</tt> should likewise be documented.  Examples:

        <div class="code">while (i < count) {
    ...
}  /* while (i < count) */

if (flag) {
    ...
} else {  /* !flag */
    ...
}  /* if (flag) */

for (node = first; node != NULL; node = node-&gt;next) {
    ...
}  /* for all nodes */</div></li>

<li class="spaced"><tt>case</tt> and <tt>default</tt> labels for a <tt>switch</tt>
        should be indented half of a normal indentation unit (two columns)
        from the line containing the <tt>switch</tt> with which they are
        associated; statements associated with a case should be indented a
        full unit from the line containing the <tt>switch</tt> (half a unit
        from the <tt>case</tt>).  If a case requires its own block, such as
        when it declares its own local variables, the opening brace is
        placed after the colon on the <tt>case</tt> line.  Example:

        <div class="code">switch (variable) {
  case 123: {
    int foo;
    ...
    break;
  }  /* case 123 */
  default:
    ...
    return -1;
}</div></li>

<li class="spaced">When a case in a <tt>switch</tt> block does not contain a
        <tt>break</tt> (or <tt>return</tt>) statement and deliberately
        "falls through" to the next case, a comment to this effect should
        be made at the bottom of the case.  Example:

        <div class="code">switch (state) {
  case 0:
    ...
    /* fall through */
  case 1:
    ...
    break;
}</div></li>

<li class="spaced">Inline comments (comments placed to the right of a line of code)
        should be aligned to start on the same column, when this does not
        place too much space between the comment and the code or cause the
        line to exceed 79 columns in length.  Inline comments after
        unusually long lines (such as long field declarations in
        structures) should be placed alone on the following line, indented
        the proper amount.</li>

<li class="spaced">The <tt>goto</tt> statement should not be used except in error
        handling situations where it will help avoid multiple levels of
        <tt>if</tt> nesting or other awkward code.  Labels for
        <tt>goto</tt> should be outdented half of an indentation unit
        from the surrounding code (<i>i.e.</i>, indented two columns less
        than the surrounding code).</li>
</ul>

<p class="backlink"><a href="#top">Back to top</a></p>

<!------------------------------------------------------------------------>
<hr/>

<h3 class="subsection-title" id="s2">D-2. Identifier naming</h3>

<ul>
<li class="spaced">Global variables and type names should use mixed upper- and
        lower-case, with an upper-case letter at the beginning of each
        distinct word in the name.</li>

<li class="spaced">Preprocessor constants and macros should use all upper-case
        letters, with an underscore between distinct words in the
        name.</li>

<li class="spaced">Structure names and local variables should use all lower-case
        letters, with an underscore between distinct words in the
        name.</li>

<li class="spaced">Structure names for structures with an associated type name
        (<i>i.e.</i>, from <tt>typedef</tt>) should be given the same name
        as the type, except with all letters in lowercase and followed by
        an underscore.  Example:

        <div class="code">typedef struct mytype_ MyType;
struct mytype_ {
    MyType *next, *prev;
    ...
};</div></li>

<li class="spaced">Names should be descriptive.  For global variables,
        preprocessor macros and constants, type names, and structure
        names, names should generally consist of one or more full words.
        For local variables, short names and abbreviations are permitted
        as long as it is clear what the variables are used for.  In
        general, one-letter local variable names should not be used other
        than the following:
        <ul>
        <li><tt>c</tt>: character</li>
        <li><tt>f</tt>: file pointer (<tt>FILE *</tt>)</li>
        <li><tt>i</tt>, <tt>j</tt>, <tt>k</tt>: integers (usually
                counters)</li>
        <li><tt>n</tt>, <tt>p</tt>, <tt>q</tt>: integers (<tt>p</tt> may
                also be a pointer variable)</li>
        <li><tt>s</tt>: string</li>
        <li><tt>t</tt>: string or temporary variable</li>
        <li><tt>x</tt>, <tt>y</tt>, <tt>z</tt>: integers (usually
                position variables)</li>
        </ul>
        Two-letter variable names are often formed from initials of type
        names, such as <tt>NickInfo *ni</tt>; see the source code for
        examples.</li>
</ul>

<p class="backlink"><a href="#top">Back to top</a></p>

<!------------------------------------------------------------------------>
<hr/>

<p class="backlink"><a href="index.html">Table of Contents</a></p>

</body>
</html>
Revision:	3389
Committed:	Fri Apr 25 14:12:15 2014 UTC (12 years, 2 months ago) by michael
Content type:	text/html
File size:	12957 byte(s)
Log Message:	- Imported ircservices-5.1.24
#	User	Rev	Content
1	michael	3389	<?xml version="1.0" encoding="ISO-8859-1"?>
2			<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11-strict.dtd">
3			<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
4			<head>
5			<meta http-equiv="Content-Style-Type" content="text/css"/>
6			<style type="text/css">@import "style.css";</style>
7			<title>IRC Services Technical Reference Manual - Appendix D. Coding style guidelines</title>
8			</head>
9
10			<body>
11			<h1 class="title" id="top">IRC Services Technical Reference Manual</h1>
12
13			<h2 class="section-title">Appendix D. Coding style guidelines</h2>
14
15			<p class="section-toc">
16			D-1. <a href="#s1">Formatting</a>
17			<br/>D-2. <a href="#s2">Identifier naming</a>
18			</p>
19
20			<p class="backlink"><a href="index.html">Table of Contents</a></p>
21
22			<!------------------------------------------------------------------------>
23			<hr/>
24
25			<p>The following guidelines were observed when writing the Services source
26			code. Note, however, that they were treated as guidelines, not rules, with
27			the cardinal rule being "readability first".</p>
28
29			<!------------------------------------------------------------------------>
30			<hr/>
31
32			<h3 class="subsection-title" id="s1">D-1. Formatting</h3>
33
34			<ul>
35			<li class="spaced">Lines must not be longer than 79 columns.</li>
36
37			<li class="spaced">The basic indentation unit is four columns.</li>
38
39			<li class="spaced">Tab (ASCII <tt>\011</tt>) characters are not permitted
40			in source files; indents should always be done using using spaces
41			(<tt>\040</tt>). The source files distributed with Services
42			include settings for the Emacs and Vim editors that cause the Tab
43			key to insert spaces rather than a tab character.</li>
44
45			<li class="spaced">Only one statement is allowed per line. Statements
46			(including the empty statement "<tt>;</tt>") may not be written on
47			the same line as a control keyword (<tt>if</tt>, <tt>for</tt>, or
48			<tt>while</tt>).</li>
49
50			<li class="spaced">Spaces are placed between binary operators and their
51			operands, except for the member-reference operators "<tt>-></tt>"
52			and "<tt>.</tt>"; spaces are not placed between unary operators and
53			their operands. However, spaces may be omitted around binary
54			operators when it would improve readability. Examples:
55
56			<div class="code">i = j * 2;
57			user->channelcount++;
58			result += i*60 + (j+59)/60;</div></li>
59
60			<li class="spaced"><tt>NULL</tt>, not <tt>0</tt>, should always be used in
61			pointer comparisons. For character comparisons, <tt>0</tt> is
62			preferred to <tt>'\0'</tt>, but the latter may also be used if it
63			does not go against the style of the surrounding code. Do not use
64			<tt>'\0'</tt> with variables declared as type <tt>int8</tt> or
65			<tt>uint8</tt>, even though these types are usually equivalent to
66			<tt>char</tt> and <tt>unsigned char</tt>.</li>
67
68			<li class="spaced">The construct "<tt>!!<i>expression</i></tt>" should not
69			be used. Use "<tt><i>expression</i> != 0</tt>" (for characters or
70			integers) or "<tt><i>expression</i> != NULL</tt>" (for pointers)
71			instead.</li>
72
73			<li class="spaced">Parentheses are required when <tt>&&</tt> and
74			<tt>\|\|</tt> are used in the same expression to explicitly indicate
75			order of evaluation; do not rely on the default order of evaluation.
76			(Not using parentheses will generate a warning when using <tt>gcc
77			-Wall</tt>.)</li>
78
79			<li class="spaced">Parentheses following the control statements "<tt>if</tt>",
80			"<tt>for</tt>", and "<tt>while</tt>", as well as the macros
81			<tt>LIST_FOREACH</tt>, <tt>LIST_FOREACH_SAFE</tt>, and
82			<tt>ARRAY_FOREACH</tt>, are preceded by a space. Parentheses
83			following function or macro calls (other than the above) are not
84			preceded by a space. Example:
85
86			<div class="code">if (flag)
87			function();</div></li>
88
89			<li class="spaced">Spaces are placed after the comma of each parameter to a
90			function or macro; however, they may be omitted in function calls
91			which are themselves parameters to a function or macro, or when
92			including them would make the line exceed the length limit. Spaces
93			are also placed after (but not before) the semicolons in a
94			<tt>for</tt> statement. Spaces are not placed after the opening
95			parenthesis or before the closing parenthesis of a function/macro
96			call or control statement. Examples:
97
98			<div class="code">function(param1, param2);
99			function(param1, strchr(string,'/'), param3);
100			for (i = 0; i < count; i++) ...</div></li>
101
102			<li class="spaced">Opening braces of control statement blocks go on the
103			same line as the control statement (<tt>if</tt>, <tt>for</tt>,
104			etc.) associated with the block; function blocks and "naked blocks"
105			(those not associated with any control statement or function) have
106			the opening brace alone on a line, indented to the same level as
107			the surrounding code. Closing braces are indented to the same
108			level as the line containing the opening brace. Examples:
109
110			<div class="code">if (flag) {
111			/* indented code goes here */
112			...
113			}
114
115			int function(int param1, char *param2)
116			{
117			/* indented code goes here */
118			...
119			/* start of a naked block */
120			{
121			int foo;
122			...
123			}
124			}</div></li>
125
126			<li class="spaced">If an <tt>if</tt> statement is longer than one line, it
127			should be broken at logical operators (<tt>&&</tt> or <tt>\|\|</tt>);
128			the operator should be placed at the beginning of the next line,
129			and should be indented to show which term the operator belongs
130			with. The closing parenthesis for the <tt>if</tt> statement and
131			the subsequent open brace should be alone on a line, aligned with
132			the first line of the <tt>if</tt> statement. (Braces are required
133			in this case.) Conditions for <tt>for</tt> and <tt>while</tt>
134			statements should never span multiple lines, though a <tt>for</tt>
135			statement may be broken at the semicolons if necessary. Examples:
136
137			<div class="code">if (ok && (strcmp(option, "option-name-1") == 0
138			\|\| strcmp(option, "option-name-2") == 0)
139			) {
140			...
141			}
142
143			if (!init_first()
144			\|\| !init_second()
145			\|\| !init_third()
146			\|\| !init_fourth()
147			) {
148			/* This example outdents the \|\| by three spaces to line
149			* up the terms. Such outdenting is acceptable if it
150			* makes the code easier to read and understand. */
151			...
152			}
153
154			for (exception = first_maskdata(MD_EXCEPTION); exception != NULL;
155			exception = next_maskdata(MD_EXCEPTION)
156			) {
157			...
158			}</div></li>
159
160			<li class="spaced">An <tt>else</tt> followed by an <tt>if</tt> is considered to be a
161			single keyword, "<tt>else if</tt>". The <tt>if</tt> part should
162			always be placed on the same line as and immediately following the
163			<tt>else</tt>; the <tt>else if</tt> should never be split up onto
164			two lines, nor should braces be used around the <tt>if</tt> block.
165			The exception to this is when the <tt>else</tt> and <tt>if</tt>
166			refer to two conceptually distinct sets of conditions, in which
167			case the <tt>if</tt> block should be enclosed by braces and
168			indented. Example:
169
170			<div class="code">res = check_password( /* ... */ );
171			if (res == 0) {
172			...
173			} else if (res == 1) {
174			/* "else if" on a single line */
175			...
176			} else {
177			if (user->ni != NULL) {
178			/* "if" condition is different from "else"
179			* condition, thus separate */
180			...
181			}
182			}</div></li>
183
184			<li class="spaced">Braces are always placed around the body of a control statement
185			(<tt>if</tt>, <tt>for</tt>, etc.). The two exceptions are
186			<tt>else</tt> followed by <tt>if</tt>, mentioned above, and
187			statements for which the body, as well as the bodies of any
188			<tt>else if</tt> or <tt>else</tt> statements for an <tt>if</tt>
189			statement, are all one statement in length and do not contain any
190			nested control statements; in this latter case, braces are optional
191			(but recommended if any of the statements span multiple lines).
192			Examples:
193
194			<div class="code">for (i = 0; i < count; i++)
195			function(i);
196
197			while (!done) {
198			/* Braces required because of the nested "if" */
199			if (do_stuff())
200			done = 1;
201			}
202
203			if (state == 0) {
204			a = b;
205			} else if (state == 1) {
206			/* Every if/else body gets braces because this body
207			* has two statements */
208			b += a;
209			a = 0;
210			} else {
211			state = 0;
212			}</div></li>
213
214			<li class="spaced">When using multiply-nested control statements, or a single control
215			statement which has a long block, the closing brace of the block
216			should be followed by a comment indicating what control statement
217			the block belongs to. This should usually be the content of the
218			control statement, but may be abbreviated as long as its meaning is
219			clear. If a long <tt>if</tt> block is followed by an <tt>else</tt>
220			clause, the <tt>else</tt> should likewise be documented. Examples:
221
222			<div class="code">while (i < count) {
223			...
224			} /* while (i < count) */
225
226			if (flag) {
227			...
228			} else { /* !flag */
229			...
230			} /* if (flag) */
231
232			for (node = first; node != NULL; node = node->next) {
233			...
234			} /* for all nodes */</div></li>
235
236			<li class="spaced"><tt>case</tt> and <tt>default</tt> labels for a <tt>switch</tt>
237			should be indented half of a normal indentation unit (two columns)
238			from the line containing the <tt>switch</tt> with which they are
239			associated; statements associated with a case should be indented a
240			full unit from the line containing the <tt>switch</tt> (half a unit
241			from the <tt>case</tt>). If a case requires its own block, such as
242			when it declares its own local variables, the opening brace is
243			placed after the colon on the <tt>case</tt> line. Example:
244
245			<div class="code">switch (variable) {
246			case 123: {
247			int foo;
248			...
249			break;
250			} /* case 123 */
251			default:
252			...
253			return -1;
254			}</div></li>
255
256			<li class="spaced">When a case in a <tt>switch</tt> block does not contain a
257			<tt>break</tt> (or <tt>return</tt>) statement and deliberately
258			"falls through" to the next case, a comment to this effect should
259			be made at the bottom of the case. Example:
260
261			<div class="code">switch (state) {
262			case 0:
263			...
264			/* fall through */
265			case 1:
266			...
267			break;
268			}</div></li>
269
270			<li class="spaced">Inline comments (comments placed to the right of a line of code)
271			should be aligned to start on the same column, when this does not
272			place too much space between the comment and the code or cause the
273			line to exceed 79 columns in length. Inline comments after
274			unusually long lines (such as long field declarations in
275			structures) should be placed alone on the following line, indented
276			the proper amount.</li>
277
278			<li class="spaced">The <tt>goto</tt> statement should not be used except in error
279			handling situations where it will help avoid multiple levels of
280			<tt>if</tt> nesting or other awkward code. Labels for
281			<tt>goto</tt> should be outdented half of an indentation unit
282			from the surrounding code (<i>i.e.</i>, indented two columns less
283			than the surrounding code).</li>
284			</ul>
285
286			<p class="backlink"><a href="#top">Back to top</a></p>
287
288			<!------------------------------------------------------------------------>
289			<hr/>
290
291			<h3 class="subsection-title" id="s2">D-2. Identifier naming</h3>
292
293			<ul>
294			<li class="spaced">Global variables and type names should use mixed upper- and
295			lower-case, with an upper-case letter at the beginning of each
296			distinct word in the name.</li>
297
298			<li class="spaced">Preprocessor constants and macros should use all upper-case
299			letters, with an underscore between distinct words in the
300			name.</li>
301
302			<li class="spaced">Structure names and local variables should use all lower-case
303			letters, with an underscore between distinct words in the
304			name.</li>
305
306			<li class="spaced">Structure names for structures with an associated type name
307			(<i>i.e.</i>, from <tt>typedef</tt>) should be given the same name
308			as the type, except with all letters in lowercase and followed by
309			an underscore. Example:
310
311			<div class="code">typedef struct mytype_ MyType;
312			struct mytype_ {
313			MyType next, prev;
314			...
315			};</div></li>
316
317			<li class="spaced">Names should be descriptive. For global variables,
318			preprocessor macros and constants, type names, and structure
319			names, names should generally consist of one or more full words.
320			For local variables, short names and abbreviations are permitted
321			as long as it is clear what the variables are used for. In
322			general, one-letter local variable names should not be used other
323			than the following:
324			<ul>
325			<li><tt>c</tt>: character</li>
326			<li><tt>f</tt>: file pointer (<tt>FILE *</tt>)</li>
327			<li><tt>i</tt>, <tt>j</tt>, <tt>k</tt>: integers (usually
328			counters)</li>
329			<li><tt>n</tt>, <tt>p</tt>, <tt>q</tt>: integers (<tt>p</tt> may
330			also be a pointer variable)</li>
331			<li><tt>s</tt>: string</li>
332			<li><tt>t</tt>: string or temporary variable</li>
333			<li><tt>x</tt>, <tt>y</tt>, <tt>z</tt>: integers (usually
334			position variables)</li>
335			</ul>
336			Two-letter variable names are often formed from initials of type
337			names, such as <tt>NickInfo *ni</tt>; see the source code for
338			examples.</li>
339			</ul>
340
341			<p class="backlink"><a href="#top">Back to top</a></p>
342
343			<!------------------------------------------------------------------------>
344			<hr/>
345
346			<p class="backlink"><a href="index.html">Table of Contents</a></p>
347
348			</body>
349			</html>