standards.texi

早期freebsd实现

cross-operation is not a meaningful thing.

Some programs have ways of configuring themselves automatically.  If
your program is set up to do this, your @code{configure} script can simply
ignore most of its arguments.


@node Source Language
@chapter Using Languages Other Than C

Using a language other than C is like using a non-standard feature: it
will cause trouble for users.  Even if GCC supports the other language,
users may find it inconvenient to have to install the compiler for that
other language in order to build your program.  So please write in C.

There are three exceptions for this rule:

@itemize @bullet
@item
It is okay to use a special language if the same program contains an
interpreter for that language.

Thus, it is not a problem that GNU Emacs contains code written in Emacs
Lisp, because it comes with a Lisp interpreter.

@item
It is okay to use another language in a tool specifically intended for
use with that language.

This is okay because the only people who want to build the tool will be
those who have installed the other language anyway.

@item
If an application is not of extremely widespread interest, then perhaps
it's not important if the application is inconvenient to install.
@end itemize

@node Formatting
@chapter Formatting Your Source Code

It is important to put the open-brace that starts the body of a C
function in column zero, and avoid putting any other open-brace or
open-parenthesis or open-bracket in column zero.  Several tools look
for open-braces in column zero to find the beginnings of C functions.
These tools will not work on code not formatted that way.

It is also important for function definitions to start the name of the
function in column zero.  This helps people to search for function
definitions, and may also help certain tools recognize them.  Thus,
the proper format is this:

@example
static char *
concat (s1, s2)        /* Name starts in column zero here */
     char *s1, *s2;
@{                     /* Open brace in column zero here */
  @dots{}
@}
@end example

@noindent
or, if you want to use @sc{ANSI} C, format the definition like this:

@example
static char *
concat (char *s1, char *s2)
@{
  @dots{}
@}
@end example

In @sc{ANSI} C, if the arguments don't fit nicely on one line,
split it like this:

@example
int
lots_of_args (int an_integer, long a_long, short a_short,
              double a_double, float a_float)
@dots{}
@end example

For the body of the function, we prefer code formatted like this:

@example
if (x < foo (y, z))
  haha = bar[4] + 5;
else
  @{
    while (z)
      @{
        haha += foo (z, z);
        z--;
      @}
    return ++x + bar ();
  @}
@end example

We find it easier to read a program when it has spaces before the
open-parentheses and after the commas.  Especially after the commas.

When you split an expression into multiple lines, split it
before an operator, not after one.  Here is the right way:

@example
if (foo_this_is_long && bar > win (x, y, z)
    && remaining_condition)
@end example

Try to avoid having two operators of different precedence at the same
level of indentation.  For example, don't write this:

@example
mode = (inmode[j] == VOIDmode
        || GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])
        ? outmode[j] : inmode[j]);
@end example

Instead, use extra parentheses so that the indentation shows the nesting:

@example
mode = ((inmode[j] == VOIDmode
         || (GET_MODE_SIZE (outmode[j]) > GET_MODE_SIZE (inmode[j])))
        ? outmode[j] : inmode[j]);
@end example

Insert extra parentheses so that Emacs will indent the code properly.
For example, the following indentation looks nice if you do it by hand,
but Emacs would mess it up:

@example
v = rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
    + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000;
@end example

But adding a set of parentheses solves the problem:

@example
v = (rup->ru_utime.tv_sec*1000 + rup->ru_utime.tv_usec/1000
     + rup->ru_stime.tv_sec*1000 + rup->ru_stime.tv_usec/1000);
@end example

Format do-while statements like this:

@example
do
  @{
    a = foo (a);
  @}
while (a > 0);
@end example

Please use formfeed characters (control-L) to divide the program into
pages at logical places (but not within a function).  It does not matter
just how long the pages are, since they do not have to fit on a printed
page.  The formfeeds should appear alone on lines by themselves.


@node Comments
@chapter Commenting Your Work

Every program should start with a comment saying briefly what it is for.
Example: @samp{fmt - filter for simple filling of text}.

Please put a comment on each function saying what the function does,
what sorts of arguments it gets, and what the possible values of
arguments mean and are used for.  It is not necessary to duplicate in
words the meaning of the C argument declarations, if a C type is being
used in its customary fashion.  If there is anything nonstandard about
its use (such as an argument of type @code{char *} which is really the
address of the second character of a string, not the first), or any
possible values that would not work the way one would expect (such as,
that strings containing newlines are not guaranteed to work), be sure
to say so.

Also explain the significance of the return value, if there is one.

Please put two spaces after the end of a sentence in your comments, so
that the Emacs sentence commands will work.  Also, please write
complete sentences and capitalize the first word.  If a lower-case
identifer comes at the beginning of a sentence, don't capitalize it!
Changing the spelling makes it a different identifier.  If you don't
like starting a sentence with a lower case letter, write the sentence
differently (e.g. ``The identifier lower-case is @dots{}'').

The comment on a function is much clearer if you use the argument
names to speak about the argument values.  The variable name itself
should be lower case, but write it in upper case when you are speaking
about the value rather than the variable itself.  Thus, ``the inode
number @var{node_num}'' rather than ``an inode''.

There is usually no purpose in restating the name of the function in
the comment before it, because the reader can see that for himself.
There might be an exception when the comment is so long that the function
itself would be off the bottom of the screen.

There should be a comment on each static variable as well, like this:

@example
/* Nonzero means truncate lines in the display;
   zero means continue them.  */

int truncate_lines;
@end example

Every @samp{#endif} should have a comment, except in the case of short
conditionals (just a few lines) that are not nested.  The comment should
state the condition of the conditional that is ending, @emph{including
its sense}.  @samp{#else} should have a comment describing the condition
@emph{and sense} of the code that follows.  For example:

@example
#ifdef foo
  @dots{}
#else /* not foo */
  @dots{}
#endif /* not foo */
@end example

@noindent
but, by contrast, write the comments this way for a @samp{#ifndef}:

@example
#ifndef foo
  @dots{}
#else /* foo */
  @dots{}
#endif /* foo */
@end example


@node Syntactic Conventions
@chapter Clean Use of C Constructs

Please explicitly declare all arguments to functions.
Don't omit them just because they are ints.

Declarations of external functions and functions to appear later
in the source file should all go in one place near the beginning of
the file (somewhere before the first function definition in the file),
or else should go in a header file.  Don't put extern declarations
inside functions.

Don't declare multiple variables in one declaration that spans lines.
Start a new declaration on each line, instead.  For example, instead
of this:

@example
int    foo,
       bar;
@end example

@noindent
write either this:

@example
int foo, bar;
@end example

@noindent
or this:

@example
int foo;
int bar;
@end example

@noindent
(If they are global variables, each should have a comment preceding it
anyway.)

When you have an if-else statement nested in another if statement,
always put braces around the if-else.  Thus, never write like this:

@example
if (foo)
  if (bar)
    win ();
  else
    lose ();
@end example

@noindent
always like this:

@example
if (foo)
  @{
    if (bar)
      win ();
    else
      lose ();
  @}
@end example

If you have an if statement nested inside of an else statement,
either write @code{else if} on one line, like this,

@example
if (foo)
  @dots{}
else if (bar)
  @dots{}
@end example

@noindent
with its then-part indented like the preceding then-part, or write the
nested if within braces like this:

@example
if (foo)
  @dots{}
else
  @{
    if (bar)
      @dots{}
  @}
@end example

Don't declare both a structure tag and variables or typedefs in the
same declaration.  Instead, declare the structure tag separately
and then use it to declare the variables or typedefs.

Try to avoid assignments inside if-conditions.  For example, don't
write this:

@example
if ((foo = (char *) malloc (sizeof *foo)) == 0)
  fatal ("virtual memory exhausted");
@end example

@noindent
instead, write this:

@example
foo = (char *) malloc (sizeof *foo);
if (foo == 0)
  fatal ("virtual memory exhausted");
@end example

Don't make the program ugly to placate lint.  Please don't insert any
casts to void.  Zero without a cast is perfectly fine as a null
pointer constant.


@node  Names
@chapter Naming Variables and Functions

Please use underscores to separate words in a name, so that the Emacs
word commands can be useful within them.  Stick to lower case; reserve
upper case for macros and enum constants, and for name-prefixes that
follow a uniform convention.

For example, you should use names like @code{ignore_space_change_flag};
don't use names like @code{iCantReadThis}.

Variables that indicate whether command-line options have been
specified should be named after the meaning of the option, not after
the option-letter.  A comment should state both the exact meaning of
the option and its letter.  For example,

@example
/* Ignore changes in horizontal whitespace (-b).  */